Ground Operations Aerospace Language 



GOAL 

Final Report 

Volume III 

Data Bank 



(SASA-CE-1 36779) GBOOHD OBEBATIOHS N74-15889 

AEBOSFACE LiNG0A6£ (GOAL). VOLUHE 3: 
DiaA BAIIK final fieport rinternational 

Business Hachines Corp.) 139 p BC $9.00 Unclas 

CSCX 09B G3/08 28967 




31 July 1973 



Ground Operations Aerospace Language 



GOAL 

Final Report 

Volume III 

Data Bank 



Contract NAS 10-6900 




Approved ^"1 J^L-^^yiiAiif^ 

//3. W, Hantfley, Manager 

L/ Systems Programming and 

Advanced Programs 




===?= Federal Systemi Division 31 July 1973 



TABLE OF CONTENTS 

Section Title Page 

1.0 INTRODUCTION— 1-1 

2.0 CONVENTIONAL PROGRAM I/O DEVICE ADDRESSING 2-1 

2.1 Early Binding - 2-1 

2.2 Modified Early Binding 2-1 

2.3 Late Binding 2-2 

3.0 MEASUREMENT ADDRESSING IN SENS0R-6ASED PROGRAMMING- 3-1 

3.1 Binding in Saturji/Apollo Software 3-1 

3.2 Binding in the Goal Language 3-2 

3.3 Extensions of Data Bank Usage Into Other 

Areas — 3-2 

4.0 IMPLEMENTATION OF LATE BINDING 4-1 

4.1 Late Binding in Goal 4-2 

4.2 Late Binding in a Goal System-Examples 4-2 

5.0 MISCELLANEOUS - 5-1 

5.1 Another Requirement for an Online Data Bank- 5-1 

5.2 The Effect of Measurement Names on Data 

Bank Usage - 5-2 

5.3 Multiple Addressing Conventions for Online 
Keyboard Usage 5-3 

5.4 Implications of a Two-Data Bank System 5-6 

APPENDIX A The Data Bank File Design - A-1 

APPENDIX B The Data Bank Functional Design B-1 

APPENDIX C DASD Size Estimates for Goal Data Bank 

Implementation C-1 

APPENDIX D Program Module Uescriptions D-1 

APPENDIX E Data Record Formats - - E-1 



TABLE OF CONTENTS (Cont) 

Section Title Page 

APPENDIX F Sample Control -Card Input F-1 

APPENDIX G Data Bank Maintenance Module Error Messages- G-1 

APPENDIX H Pre-Processor Error Message List H-1 

APPENDIX I Data Bank Pre-Processor Syntax Tables I-l 



n 



1.0 INTRODUCTION 

The GOAL (Ground Operations Aerospace Language) test programming language 
was developed for use in ground checkout operations in a space vehicle 
launch environment. To insure compatibility with a maximum number of 
applications, a systematic and error-free method of referencing command/ 
response (analog and digital) hardware measurements is a principle feature 
of the language. Central to the concept of requiring the test language 
to be independent of launch conqslex test equipment and terminology is 
that of addressing measurements via symbolic names that have meaning 
directly in the hardware units being tested. To form the link from test 
program through test system interfaces to the units being tested the con- 
cept of a data bank has been Introduced. The data bank Is actually a 
large cross-reference table that provides pertinent hardware data such 
as interface unit addresses, data bus routings, or any other system values 
required to locate and access measurements. 

Three aspects of future aerospace operations can be considered key when 
determining whether single or multiple data bank(s) can be justified. 
First, the management of a very large number of sensor based measurements 
at distinct facilities constitutes a large engineering management effort. 
Secondly, verification and launch checkout of future ground and flight 
hardwares will require use of this large measurements base in conjunction 
with the generation of a large body of automation and test program software 
packages. A third problem area is then created when combining certain aspects 
of the first two - when hardware modifications are required as a result of 
normal or abnormal operations these changes must be carried over into the 
software programs also. The solutions to any or all of these problems are 
further degraded when confronted with the potential space shuttle environ- 
ment of tight launch schedules involving multiple vehicles. 

Little can be accomplished in alleviating the problems of the large measure- 
ments base or the large number of required test programs as these items are 
controlled by engineering factors not under direct control of ground data 
processing systems. Data processing equipments can be effectively used in 
the support of the ground checkout and launch "business" just as they have 
been in other applications of the scientific and commercial world. The 
GOAL test programming language has evolved as an attempt at alleviating 
the problem of generating and managing a large number of test programs. 
The use of a data bank in conjunction with the GOAL language is vital since 
its sole purpose is to assist the programmer in dealing with a large and 
variable set of measurements and to make as easy as possible the intro- 
duction of the effects of hardware changes into the test programming system. 
Accordingly, throughout the remainder of this document, the aspect of mean- 
ingful use of measurements and the software impacts of hardware measurements 
changes will be discussed over and over again. A significant portion of this 
document will deal with suggestions as to improvement of operations using 
the GOAL language compiler data bank and extending the use of a measurements 
data bank into online use in ground operations. 



1-1 



2.0 CONVENTIONAL PROGRAM I/O DEVICE ADDRESSING 

2.1 EARLY BINDING 

In general, software communication with any external computer accessible 
device is considered an input/output operation. The process of associating 
actual device addresses with input/output instruction sequences is known 
as "binding" 1n data processing parlance. The binding of device addresses 
to I/O instruction can be effectively accomplished at or before program 
execution. 

"Early binding" techniques have been customary in the past with compiled 
high level languages such as FORTRAN. Thus, at the time that the pro- 
grammer coded the sequence 

WRITE (6,10) A, B, C 

directing output to symbolic device #6, it had already been determined 
(usually by compiler decree) that device #6 was to be, for instance, a 
tape drive at device address A. Once compiled, only tape drive A could 
be used as a target for the output operations directed to device #6. If 
for unseen reasons tape drive A was not operational, the early binding 
of this device address A to the symbolic name 6 forces one of the follow- 
ing two alternates: 

1. If at all possible, the program run is held in abeyance until 
the required tape drive becomes operational. 

2. If the program must be run, a workaround for the required hard- 
ware address change must be effected. In the traditional early binding 
situation for FORTRAN, the following steps are required: 

Assign an alternate tape drive to replace the non- 
operational drive A. Assume that tape drive C 
(symbolic address #8) was available. 

The FORTRAN source program is then modified such 
that every WRITE statement addressing device #6 
is redirected to device #8. The statements of 
concern must be repunched. 

The revised source program must then be recompiled 
prior to its use. 

2.2 MODIFIED EARLY BINDING 

A significant Improvement to the classic early binding problem can be 
effected by associating symbolic device addresses with actual hardware 
addresses via compiler control cards or special source program control 
cards at compile time. Thus, with "modified early binding" the problem 



2-1 



of the previous FORTRAN example would be resolved by modifying a device 
control card and recompilation of the source program. Note that modifi- 
cations to the actual source program are no longer required in this 
instance - this could amount to a significant number of changes in many 
programs. Several progranming languages have directly or indirectly 
adopted this technique of improved early binding. For instance, the 
sole purpose for the ENVIRONMENT DIVISION Section of a COBOL program 
is to implement this feature. 

2.3 LATE BINDING 

"Late binding" became a reality with some of the more advanced Operating 
Systems available late in the so-called 2nd Generation era of software. 
With late binding, the actual hardware address versus symbolic address 
linkage is to be made after compilation. Thus, the salient feature of 
this type of binding is that no source program modifications or re- 
compilations are required to accommodate device address changes. Late 
binding is usually one of the service functions of an Operating System. 
The actual binding or device selection is customarily performed imme- 
diately before execution of the program involved. In the selection of 
specific devices for allocation to a program, the Operating System may 
follow control card direction as to exactly which device is desired; 
some Operating Systems are capable of selecting any appropriate device 
from a pool of available devices. 



2-2 



3.0 MEASUREMENT ADDRESSING IN SENSOR-BASED PROGRAMMING 

The data processing environment in which a sensor-base (process control) 
program must operate 1s 1n many areas parallel with the traditional batch 
scientific or commercial environment. As such, many of the tried and true 
solutions to traditional batch programming problems can be expected to 
bear similar fruit in the process control environment. The two environ- 
ments are not the same, however, and It should not be surprising if some 
of the solutions to the past problems do not yield equivalent results; 
in some instances, new solutions to new problems must be sought. 

Sensor-base measurements (discrete and analog inputs/outputs) form a set 
of simple input/output devices to manipulate - the measurements problem 
In the process control environment is not one of complexity but one of 
sheer bulk. As the total number of Input/output device addresses grows 
larger, the possibility of an individual address change becomes more 
significant. Experience has also shown that the negative aspects of the 
software binding techniques discussed previously become more intractable 
for the case of managing a system of process control programs. For instance, 
a single discrete measurement address change may require several hundred 
changes to a dozen or so programs - all of which must then be recompiled 
and reintroduced to the online system before run time. 

3.1 BINDING IN SATURN/APOLLO SOFTWARE 

In the process-control environment of SATURN/APOILO, the discrete or analog 
measurement symbolic name and measurement hardware address were synonymous. 
By the choice of such a symbolic naming scheme, early binding of symbolic 
name and hardware address was forced on the process -control software - at 
the assembler language level as well as at the high-order language level. 
Thus, the following succession of events could be anticipated following a 
hardware change - possibly as minor as a single address modification: 

The first problem falls properly in the area of configu- 
ration management - that of finding from a system of (n) 
software modules just which ones access the measurements 
whose addresses have been changed. In general , a manual 
search of program listings has been the only method of 
solving this problem. 

Having determined which program(s) require modification, 
the imposing task of source program modification can ensue. 
Two factors accentuate the difficulty of this endeavor. 
First, It is common for a single measurement to be mentioned 
many (possibly, hundreds) of times within the bounds of a 
single program; the problem of finding and making all of the 
required changes is a very real problem. Often, "almost all" 
of the changes are located and made. Secondly, the modifi- 
cation task must in many instances be attended to by personnel 
not responsible for coding the original programs; this adds 
a factor of difficulty to any program change. 



^-1 



All. of the modified software modules must then be re- 
assembled or recompiled prior to use. Some may also 
require revalidation of program operation after changes. 
Once the update process has completed, the updated 
modules will replace the currently active modules in 
the online system. 

If the measurement address changes were only temporary, 
the above sequence of operations must be reversed to 
return the software system to its original configuration. 

3.2 BINDING IN THE GOAL LANGUAGE 

The disadvantages of early binding in the existing SATURN/APOLLO computer 
languages were well known when specifications were first drafted for GOAL 
(Ground Operations Aerospace Language). This high level language, intended 
for use in the post SATURN/APOLLO time frame introduced the concept of a 
"data bank" as a repository for all sensor-base hardware procedural, 
addressing, and routing data. With the initial implementation of the 
GOAL language, this data bank took the form of a disk-resident file from 
which the GOAL compiler could randomly access data relative to all avail- 
able measurements. GOAL also introduced a meaningful symbolic naming 
scheme for all hardware measurements and classifies such devices as 
"function designators." As an example, the discrete signal that 
activates/deactivates 28 volt stage power might have been addressed 
in the SATURN/APOLLO software via its hardware address, e.g., DISCRETE 
OUTPUT #414 - early binding of the hardware address is thus completed. 
The same measurement could be addressed in a GOAL program by the symbolic 
function designator name "28V STAGE POWER." Using the function desig- 
nator name as a search argument, the GOAL compiler would query the data 
bank during compilation and determine that a discrete output measurement 
at hardware address 414 was being referenced. This GOAL implementation 
of a modified early binding technique eliminates many of the frustrations 
of accommodating measurement address changes. All such changes will be 
introduced to the GOAL system by an update to the data bank. Recompila- 
tion of the appropriate test programs will then effect the required 
modifications in the programs. 

3.3 EXTENSIONS OF DATA BANK USAGE INTO OTHER AREAS 

One of the basic design philosophies of the GOAL language stipulates that 
a GOAL test program must have the ability of addressing measurements and 
specifying test points at the lowest level possible within the bounds of 
a given system configuration. It was recognized that the level of access 
or the method of accessing a particular measurement could vary significantly 
- dependent upon the physical or geographic site at which the program was 
to operate. 



3-2 



As an example, consider a flight component called "Box A". A test program 
is developed that will issue stimuli to Box A and measure subsequent Box A 
responses in a fashion that will verify the internal operational status 
of Box A. As illustrated in Figure 3-3-1, both the type as well as quantity 
of test hardware which might exist between the test program host computer 
and Box A could vary significantly at three geographical sites at which 
testing of Box A is required. 

At the manufacturing site, the final acceptance test 

interface is shown as comprising a simple hybrid set- "^ 

up solely dedicated to the testing of Box A. 

At the launch site, Box A assumes the role of a single 
component within a complex vehicular hardware system. 
The test interface in this instance is quite complex 
since it addresses the entire vehicle - only a small 
portion of the overall interface can be dedicated to 
the control or testing of Box A. 

During preventive or fault isolation maintenance, a 
third variant of interface exists between the test 
program and Box A. In this instance, controllable 
diagnostic test hardware has been introduced. Al- 
though Box A is shown as being the sole object of 
test, maintenance testing could well have been 
directed at a larger system within which Box A was 
a minor component. 

In each of the instances in the example, the contents and operation of 
the test program could be assumed to be constant, i.e., the procedure 
used for the internal verification testing of Box A is the same ir- 
respective of the location of Box A. The method of sensor-based 
measurement address binding now becomes most significant. If early 
binding is chosen, the test program must be programmed in a unique 
manner in each of the locations of the example. This implies unique 
program coding as well as unique verification of the proper operation 
of the program at each site. The function designator naming scheme 
and data bank concept of GOAL combine to make it possible to fulfill 
the test program obligations of all three sites with a single source 
program. Since each site will support its own version of the GOAL 
data bank, a compilation of the same program at each site will result 
in an executable module tailored to each of the distinct interface 
requirements. 



3-2 



Test 
Computer 



^ 



Box A 
Test 
Program 



"> 



Box 

A 



Hybrid Test 
Harness 



FINAL ACCEPTANCE TEST AT MANUFACTURING SITE 



Test 
Computer 



\ Box A 
Test 



Program 



< > 



Ground 
Interfaces 



! Additional 
' Computers 



Hardwire and 
RF Linkages 



e 



¦> 



Vehicle 




Test 
Computer 



Box A 
Test 
Program 



LAUNCH COHPLEX PRE-FLIGHT TESTING 



^ - 



^ 



Di agnostic 
Test 
Hardware 




PREVENTATIVE OR FAULT ISOLATION MAINTENANCE 



Figure 3-3-1. SAMPLE HARDWARE CONFIGURATIONS 



3-4 



4.0 IMPLEMENTATION OF LATE BINDING 

The single inconvenience encountered in a system which incorporates early 
or modified early binding is that of requiring program re-compilation to 
adjust for input/output addressing changes. Put in other words, the 
actual binding operation takes place during (and only during) compilation. 

To effect late binding, the binding process must ensue after compilation; 
this essentially divorces the compiler from binding responsibilities but 
introduces the requirement that another program accomplish the binding. 
In many modern systems this binding responsibility will be delegated as 
a utility service task for the Operating System. Generally, lack of late 
binding resources within a given data processing system can be attributed 
to one or more of the following reasons: 

Occasional recompilation of a program to adjust for 
input/output device reassignment is not considered 
by some users to be an inconvenience worth mentioning. 

That which could be cleanly designated as an "Operating 

System" Is absent in many small or so-called "mini" systems. 
The high-level language compiler {if any) of such a system 
must produce a program module that is completely self- 
supporting - it can be loaded and carried through all 
phases of execution without assistance from other pieces 
of software. Manual assistance, e.g., control-card 
direction after compilation is almost r\Q\/er required, 
nor, in most instances, possible. 

A method will be presented later in this document in 
Section 4.2 to demonstrate that late binding can be 
effectively implemented on a system which hosts only 
a computer of small capability. This would seem in 
contradiction with the statements preceding, however, 
the "small" computer of Section 4.2 will be augmented 
considerably by offline support of a larger system on 
which the burden of compilation and software binding 
will be placed. 

In some systems the effort associated with implementing 
a late binding scheme was simply not justified in the 
minds of the system designers. Not only must the high- 
level language compilers and the Operating System software 
be of greater scope, but the use of a late binding system 
is generally more complex for the programmer. 



4-1 



4.1 LATE BINDING IN GOAL 

Two features must be present in the GOAL execution -time, i.e., online, 
system if late binding is to be effected. The first is the software 
module that will actually accomplish the binding operation. This can 
be conveniently delegated to either a utility program or a utility 
service of the online operating system. The second need Is that of a 
large cross-reference table that can be used to relate symbolic measure- 
ment names to actual hardware accessing data; in other words, an online** 
data bank is required. 

Two positive factors make the operation of late binding in the GOAL 
language system distinct from the implementation customarily found in 
scientific and commercial data processing systems. First, the compile 
of a GOAL program and the execution of the same program will probably 
be accomplished on different computer systems. This means, for instance, 
that the qualifications that must be met by the computer system that 
hosts compiler operations need not be reflected or duplicated by the 
execution-time computer systems, or vice versa. Secondly, for the GOAL 
system, no appreciable user effort is required to effect or control the 
binding operation whereas traditional late binding techniques customarily 
Involve modest to extensive control -card direction by the progranmer. 

4.2 LATE BINDING IN A GOAL SYSTEM - EXAMPLES 

Piguj-e 4-2-1 illustrates the process flow of the production of a loadable 
program module v1a the first Implemented GOAL compilation process. The 
file marked "intermediate text" In this case Is the source program In 
another more readily processable format. Within the intermediate text 
file is the reformatted source program plus all applicable hardware 
addressing or usage data as supplied by the compiler data bank. In the 
Instance of Figure 4-2-1, the translator program provides the interface 
between online SYSTEM-X and the general -purpose intermediate text form 
of the user program. Each distinct online system will require a unique 
translator program. The program module shown as output from the trans- 
lator Is complete; function designator hardware binding was accomplished 
at the GOAL compilation step - in this Instance, modified early binding. 
The final step of the programming sequence is the introduction of the 
tailored program module to the program library associated with the online 
computer of SYSTEM-X. 



**"Online" is perhaps a poor choice (as will be seen later) to attach to 
the data bank associated with the binding task. For the present, let it 
suffice to say that the word "online" Is used strictly to establish a 
distinction between the online data bank and the data bank associated 
with compiler operations (the compiler data bank). 



4-2 



A possible method of accomplishing the transition from the current GOAL 
modified early binding system to a late binding variant is demonstrated 
in Figure 4-2-2. This diagram can be seen to differ significantly from 
that of the current modified early binding system of Figure 4-2-1 in the 
flow logic following the translator phase. Preceding the translator, 
the compiler data bank now contains no hardware binding data. Function 
designator data consists of symbolic name and associated hardware type 
(discrete, analog, etc.), description. The translator program of the 
late binding system accomplishes the same general functional task as 
before, i.e., translating the intermediate text format of the user pro- 
gram into an acceptable form for use on the online system. The output 
of the translator is unique In the late binding system - declared data 
and program text (direct or Indirectly executable code) are combined 
into a distinct output labeled the "program module." Associated with 
each program module is a second output from the translator - the 
"measurements table." This table will contain no_ entries for those 
programs which make no reference to external input/output devices 
(including sensor-base devices). For any other program which will 
require binding of function designator name to hardware address, the 
measurements table will contain Individual table entries - one for 
each unique function designator mentioned in the program. Each table 
entry will indicate the function designator symbolic name In con- 
junction with table space (reserved, but not filled In at translate 
time) sufficient to hold any associated hardware addressing, usage, 
accessing, scaling, or routing data. The symbolic function designator 
name will be used as a search argument when seeking hardware binding 
data from the online data bank. 

Shown in Figure 4-2-2 as a peripheral to the computer online SYSTEM-Y 
is the data bank (called the "online" data bank) from which the hard- 
ware binding data** can be extracted. Introduction of the entire program 
to the online computer program library takes place in the following two- 
step operation: 

1. The program module Is transferred and edited Into the online 
computer program library in exactly the same fashion as with the modified 
early binding system. 

2. The measurements table will be entered into the measurements table 
library via a utility program entitled the "table editor" in Figure 4-2-2. 
The table editor will locate each function designator In the online data 
bank by using its name as a search argument. Once a function designator 
has been found In the online data bank, all pertinent hardware accessing 
data (binding data) will be filled into the space reserved for it in the 
measurements table. The completed table will then be written into the 
measurements table library. 



**There Is a definite need for an online data bank for use in areas other 
than late binding support. More on this later, in Section 5.1. 



4-3 



The "program fetch" (locating and fetching a program into computer storage 
prior to its execution) operation of the online computer Operating System 
as shown in Figure 4-2-2 will require modification to accommodate location 
and load of both the program module and its associated measurements table. 
Even though late binding involves a distinction between program module and 
measurements table, no more computer memory should be required at execution 
time to support a late binding operation than that which would have been 
used in an early or modified early binding system. 

Online SYSTEM-Z as depicted in Figure 4-2-3 is offered as an example of 
extending late binding capability into a hardware system of unusually small 
capacity. The computer of online SYSTEM-Z is assumed incapable of support- 
ing an online data bank as a normal peripheral device. A practical instance 
of this situation might be in the case of a so-called "mini" computer system. 
Even in this instance, ability to accomplish late binding has significant 
advantages - predominant is the ability to accomplish binding without re- 
quiring program recompilation. The late binding operation in this system 
occurs at translate time on a computer of higher capability than the online 
mini system. The translator data bank is labeled "online" to distinguish 
it from the compiler data bank. The program module produced for use on the 
target online computer would be complete, i.e., all binding accomplished. 
The program module is not shown as entered to a program library since a 
computer system of this minimal size suggests that such a program library 
might also be beyond the support capability of the system. Tape (magnetic 
or paper) or punched cards could be an acceptable storage media for the 
program module. 



4-4 



4i 
cr 



GOAL 
Source 



._.-J^ 

GOAL 
Compiler 



n 



7K 



N 



Compiler 
Data Bank 



/ 



Intermediate 
Text 
File 



> 



SYSTEM-X 
Translator 



jii. 




Complete 

Program 

Module 



_-N 



Online SYSTEM-X 



Utility 
Program 




SYSTtM-X \ 

Program 

Library 



Online 
Computer 



Figure 4-2-1. - GOAL Program Production Flow 

As Implemented with Modified Early binding 



Online SYSTEM- Y 



r 



I 
0-, 



GOAL 

Source 

Program 




-M 




Intermediate 
Text 
File 



Compiler 
Data Bank 



Figure 4-2-2- 



GOAL Program Production Flow 
Demonstrating a Possible Late 
Binding Implementation Scheme 



Program 
Moc 



SYSTEM-Y 
"^ Translator 




Measurements 

Table 




Uti 1 i ty 
Program 



; Table 
-^ Editor 



IK 



SYSTEM- Y 

Program 

Library 



n 



- J 



SYSTEM-Y 
Measurements 
Table Library 



Online 
Data Bank 



L 



n 



Online 

Computer 



I GOAL 
I Source 
I Program 



A^. 



GOAL 
Compiler 



-Ps- 
I 



W 



Online SYSTEM-Z 



1 



-^ 



SYSTEM-Z 



7=' Translator 



Intermediate 
Text 
File 



":^" 




Compiler 
Data Bank 




Complete 

Program 

Module 



Online 
Computer 



Online 

Data Bank 



Figure 4-2-3. - Entending Late Binding Support to an Online 
tiOAL System whicn Hosts a "Mini" Computer 



5.0 MISCELLANEOUS 

5.1 ANOTHER REQUIREMENT FOR AN ONLINE DATA BANK 

Previous experience with the computer environment of SATURN/APOLLO has 
indicated that the execution of many process-control programs requires 
continual man-machine monitoring and communication. In particular, test 
programs used in fault Isolation tasks generally rely on their human 
counterpart for redirection and specific remedial actions in the detection 
and reporting of hardware anomalies. Some type of keyboard-driven terminal 
appears to be the most effective man-machine communication medium. Many 
actions that originate as a keyboard request or entry deal actively, 
passively, or both, with the status of sensor-base hardware measurements. 
If the launch complex terminal operator is to have the capability of 
formulating queries relative to the status of measurements via his key- 
board (either associated with or divorced from the operational requests 
of any test program which may be running at the time), a measurement ad- 
dressing or name convention must be established. 

As discussed previously, the SATURN/APOLLO era approach to measurement 
naming centered about hardware dependent terminology, e.g., the discrete 
measurement controlling "2nd stage LOX vents" would be referred to via its 
hardware routing "discrete output number 414" (or, simply "DO 414"). The 
rationale has already been presented as to why the GOAL test programming 
language addresses measurements by meaningful symbolic function designator 
names rather than by hardware dependent terms. The same justifications 
can be extended into the keyboard operations are to enable selection of 
a meaningful measurement convention. 

That the measurement addressing technique associated with keyboard operations 
should be the same symbolic scheme as that which has been chosen for the GOAL 
test programming language seems almost indisputable. To do otherwise would 
make it mandatory that a single unique measurement be addressable by one 
name within the bounds of a test program but require still another distinct 
"name" be used in making keyboard referral to the same measurement. The 
implications of such an incompatibility can be readily projected into the 
amount of additional training required for keyboard operator and test program 
writer personnel; a significant amount of additional hard copy support docu- 
mentation would also be required to keep track of legitimate synonymous 
measurement names and to draw parallels between the names used in manual 
keyboard operations procedural documentation and the names to be found in 
test program listings. 

When making keyboard access to measurements by hardware descriptive symbols, 
e.g., "DO 2344" (discrete output # 2344), the terminal software can easily 
transform the symbolic address to an actual hardware address. Even an 
extreme such as the more cryptic 14-character name convention used for 
Digital Data Acquisition System (DDAS) measurements in the SATURN/APOLLO 
system lends itself to ready conversion by a strictly software method into 
its physical routing equivalent. Any type of name convention whereby certain 
or all of the characters of the name impart hardware relations or processing 



b-1 



information will always appeal to those personnel whose principal tasks 
involve heavy reliance on circuit diagrams or other systems drawings or 
prints. To the keyboard operator, such a name scheme severely lacks many 
human factors attributes. First of all, it is admitted that such schemes 
yield names that are quite cryptic and therefore easily entered via key- 
board - but, such names because of their cryptic nature are difficult to 
remember exactly. Secondly, with a truly symbolic name such as "28VDC 
GROUND POWER", a spelling error (even a single character error) almost 
always results in an illegal name and the keyboard operator can be so 
notified via an appropriate error response from the online computer oper- 
ating system. On the other hand, a single character misspelling with a 
hardware codified name can many times result in a syntactically legal 
name and the logical error can pass by undetected. Consider the example 
of the single character misspelling of "DO 4144" in lieu of "DO 4145" - 
both could be completely legal references to actual measurements. The 
terminal or operating system software packages have no method whatsoever 
of making the distinction between what was requested and what was intended. 
A third difficulty arises when a measurement must be rerouted and its 
addressing changed. In the case of codified measurement names, physical 
address modification dictates revision of the symbolic measurement name 
also. Such changes in turn force "red-line" or permanent editing of 
references to the rerouted measurements in system drawings and hard- 
copy documentation. 

The introduction of function designator type name standards for keyboard 
usage implies that some type of data bank be online available to at least 
the, computer that accomplishes keyboard request processing. This require- 
ment can be merged with the desire for late binding facilities in the 
online system; a single online data bank can fulfill all obligations of 
both tasks. 

5.2 THE EFFECT OF MEASUREMENT NAMES ON DATA BANK USAGE 

As a general rule-of- thumb, when a file is used as a repository of variable 
data, it should be searched using search arguments that do not change, i.e., 
constant search arguments. Consider the everyday use of a telephone direc- 
tory; a constant name is used as a search argument to locate variable data 
(address and phone number). Assume that an individual named "J. Doe" 
maintains residences in 20 locations. It would be possible to query the 
appropriate 20 telephone directories with the constant name "J. Doe" and 
retrieve 20 variable phone numbers. Now, if the directories were restruc- 
tured to be ordered by telephone number rather than by surname, their 
usefulness (at least by human beings) becomes severely curtailed. For 
instance, with the present example, the task of determining the location 
of 20 occurrences of the constant "J. Doe" is resolved in one of two ways. 
The first technique requires that the 20 variable phone numbers (which are 
now the search arguments) be already known - in which case, of what use 
are the telephone directories? The second method dictates a serial search 
of the 20 directories; a messy proposition, even with the assistance of 
data processing equipment. 



5-2 



The above concept of utilizing constant search arguments to retrieve 
variable file contents is vital from an efficiency standpoint when 
considering the design of either the compiler or the online data banks. 
Specifically, measurement (function designator) names used as search 
arguments into data banks should be constant. This indicates that any 
name convention which uses characters of the symbolic name as indications 
of hardware routing or other access information is unacceptable for names 
used as data bank search arguments. The hardware indication characters 
of such names are subject to change, thus making the entire name a variable. 
Violations of the constant search argument principle leads to one or more 
of the following ramifications: 

The possibility of the keyboard operator utilizing one 
measurement name convention and the test program writer 
another implies that at least two or more symbolic names 
must exist for each single measurement. The net effect 
is that all readability between measurement names as they 
exist on program listings and what appears at the output 
of operations terminals disappears. 

If one name convention is used for keyboard operations and 
another for offline compiler usage, then two data banks of 
entirely distinct format and usage conventions must be 
maintained. The very real possibility of each data bank 
being in a different state of update becomes a constant 
maintenance headache - more so because such errors of 
incompatibility are virtually impossible to diagnose or 
prevent by installing software maintenance safeguards. 

In the unlikely event that the GOAL language is forced to 
relinquish the function designator name convention and adopt 
a variable name scheme, then the present GOAL test programming 
luxury of addressing the "system under test" rather than the 
"test system" must be abandoned. 

5.3 MULTIPLE ADDRESSING CONVENTIONS FOR ONLINE KEYBOARD USAGE 

In the keyboard operations area there is a definite need for an abbreviated 
method of addressing measurements. The test program writer can afford the 
time required to code with pencil long (up to 32 characters) function 
designator names. A keyboard operator will find entry of such names a 
time consuming process - particularly during the times when he must address 
several measurements in rapid succession. In an effort to establish a 
name scheme that will be useful and acceptable to a wide variety of users, 
it is obvious that more than one distinct conventions are required. The 
most important consideration to remember is that these distinct methods 
can coexist and not be in contention with one another (if implemented 
properly). If, on the other hand, one name scheme must be selected thus 
excluding all other(s), then the resulting compromises and drawbacks must 



5-3 



also be acceptable since one name convention will simply not fulfill the 
needs and desires of all users in an equitable manner. In the following 
paragraphs, a technique will be demonstrated to prove that several name 
conventions can be used in a compatible manner. The conventions themselves 
plus their individual methods of implementation must be carefully selected 
to prevent the negative aspects of one convention/implementation from 
carrying over into another area. In some aspects of the system illustrated 
below, the negative aspects of one convention/implementation can be effec- 
tively cancelled by the positive features of one or more of the other 
convention/implementations. 

Consider each sensor-based hardware measurement to be addressable as 
follows: 

1. By symbolic function designator name, e.g., 
<GROUND POWER COOLING PUMP>. 

2. By a unique "measurement number", e.g., 1436. 

3. By a symbolic name in which the characters indicate hardware 
routing of accessing information, e.g., 10/A14C2/16. 

The function designator version will follow the current GOAL language 
requirements of one to thirty-two characters enclosed within brackets. 
The measurement number mentioned in 2., above, will be a constant number 
which has been assigned to this particular measurement; each measurement 
in the system will have such a number assigned to it, starting the se- 
quence at one, 1. Of prime importance is that this number be considered 
just as "constant" as the symbolic function designator name - absolutely 
no hardware implications are present in these nuntiers. The hardware- 
dependent symbolic name mentioned in 3., above, can be formed using any 
rules suitable to the user group concerned with such terminology. The 
example extended above was generated strictly as an example. Since this 
name version utilizes hardware-dependent characters in its formation, 
the resulting name is not a constant. Certain drawbacks associated with 
using variable names as data bank search arguments were presented hitherto 
In Section 5.2. When a variable name version is used in conjunction with 
a fixed convention, most of the negative aspects of the sole use of the 
variable technique are nullified. The problem remains of assuring that 
the variable name is updated in a timely and precise manner whenever the 
inevitable measurement hardware changes occur. 

Specific rules in regards the use of the three names presented In the 
example above are as follows: 

The function designator and measurement number are 
constant and will not change throughout the life of 
the measurement. The hardware dependent version can 
be expected to change if hardware accessing modifi- 
cations are required. 



b-4 



Only the function designator name convention can be 
used in the GOAL test programming language. 

All three name versions can be used interchangeably 
for addressing measurements via keyboard terminal. 

The use of all versions at the online terminals implies that a variety of 
users can be serviced - each using the convention most suitable to his 
needs. All three versions will seek hardware accessing and scaling infor- 
mation from the appropriate measurements record of the online data bank. 
The function designator and hardware dependent versions will require a 
data bank directory search prior to locating the required measurements 
record. A significant feature associated with the measurements number 
name version is that the number can point directly to the measurements 
record. In the example, a measurement number of 1436 would lead to access 
of the 1436th data bank record; thus, no prior directory search would be 
required. The use of measurements number names would be feasible in place 
of the function designator types in the measurements table application 
mentioned in Section 4.2. This would result in an appreciable time savings 
In the update of the measurements table library; elimination of the direc- 
tory search decreases the total number of input/output operations required 
to locate a given measurements record In the data bank by approximately 75%. 

As an example of terminal output, using any one of the three names mentioned 
previously will result in the following terminal sequences: 

(keyboard 

input) <GROUND POWER COOLING PUMP>? 

(terminal 

response) <GROUND POWER COOLING PUMP> = M1436 = 10/A14C2/16 = ON 

Thus, use of any one name will result in appearance at the terminal of the 
selected name plus the other two versions in addition to the measurement 
status. The output format illustrated above was chosen carefully since 
certain drawbacks of using individual name conventions can be eliminated. 
Consider the following advantages and features: 

It was mentioned previously that a short name convention 
(like the measurement number) can be very attractive to 
a keyboard user from the standpoint of brevity and rapid 
entry. Such names are subject to misspelling errors that. 
In general, cannot be detected. For example, consider the 
following input/output sequence: 

(Inquiry) Ml 436? 

(Response) Ml 436 = ON 

If the user had entered the 1436 measurements number in 
error thinking that it was associated with the "STAGE II 
LOX VENTS", no Indication of error can be ascertained in 



5-5 



abbreviated output sequence above. The extended output 
illustrated in the previous example would have served as 
an error indication when the terminal operator noted that 
the <GROUND POWER COOLING PUMP> name was not what he intended. 

If a user was in doubt as to the exact spelling of one name 
version of a given measurement, and he knew either of the 
other two, then a simple keyboard query using the known 
name will suffice to determine the unknown version(s). This 
gives the online keyboard operator a convenient method of 
cross referencing measurement names. Consider the instance 
of a technician 1n a remote location who required the hardware 
dependent name for the "Ground Power Cooling Pump" for use in 
circuit diagram reference. Intercom correspondence with any 
available launch complex terminal operator will provide the 
required name. 

5.4 IMPLICATIONS OF A TWO-DATA BANK SYSTEM 

Consider an automation system which is supported by a general purpose GOAL 
compiler. For each active and distinct online system there also exists a 
separate translator program whose function is to tailor the general-purpose 
GOAL program module as produced by the compiler to the specific needs of 
each online system. Within the same system framework there exists a data 
bank to support compiler operations called the "compiler data bank". Each 
distinct online system will be supported by a separate "online data bank". 
The following salient features and considerations attendant to such a system; 

Maintenance of the compiler data bank with regard to function 
designators is considerably simplified in a system with two 
data banks. For each function designator, the compiler data 
bank need contain only symbolic function designator name plus 
measurement type (discrete, analog, etc.), data. Specifically, 
no addressing data is to be present in this data bank; there- 
fore, hardware addressing changes have no maintenance implica- 
tions in this data bank. Function designator maintenance within 
the compiler data bank involves only addition and deletion of 
measurements. 

Absence of hardware measurement data in the data bank asso- 
ciated with the compiler implies that only one logical data 
bank need be used at compile time to store measurement 
information for all programs. All measurement names for all 
distinct online systems can be present in the same compiler 
data bank. 

Presence of an "online data bank" implies that the keyboard 
language and the offline compiled test program language have 
consistent name conventions. 



t>-b 



To inject late binding capabilities into the GOAL test 
programming system, translator production of both a 
program module plus a separate measurements table were 
discussed in Section 4.2. As an indirect advantage of 
having the measurements used within each test program 
isolated as a separate data structure, consider the 
following hypothetical problem: "...the Stage-II AC 
Bus Overload Indicator is faulty, but cannot and need 
not be replaced until tomorrow. What test programs, 
if any, would be effected by unavailability of this 
measurement?..." Such a question could be introduced 
to the online system via keyboard. A relatively simple 
software utility routine could be devised to search the 
tables located in the measurements table library for an 
occurrence of the measurement name(s) of concern. The 
name(s) of the test programs containing such measurements 
would then be output to the terminal that initiated the 
search. The attractive aspect of seeking an online 
solution to such problems is that the answers so derived 
are generated very rapidly and 100% confidence can be 
placed in the accuracy of the results. Such information 
can form the basis for a great many technical and manage- 
rial decisions that would otherwise be either impossible 
to resolve, or so time consuming as to be impractical. 

Measurement addressing changes are introduced to the 
online system via a two-step process. First, a utility 
program is used to inject addressing modifications to 
the online data bank. This program could be run on a 
computer system distinct from the computer associated 
with the online data bank. This would be quite feasible 
in the event that the data bank was to reside on a remov- 
able disk pack. The utility operation could also be 
accomplished in an interactive manner with commands 
entered via keyboard terminal. The data bank update 
process involves locating the required measurement record 
in the online data bank by using the function designator 
name as the search argument. Once the record has been 
found, the required measurement addressing data can be 
modified and the revised record rewritten back to the 
data bank. Once all data bank update (s) have taken 
place, the second step involves starting a utility 
service program to propagate any measurement addressing 
changes into the measurements table library. The action 
of this service process would be as follows: 

* Fetch a measurements table from the library. 



5-7 



* Compare each function designator name in the 
table against the list of modified function 
designators. If present in the table, revise 
the table addressing data accordingly. 

* If any table revision has been necessary, rewrite 
the table back to the measurement table library 
and proceed with the next table. If no changes 
were required in the current table, proceed im- 
mediately with the processing of any remaining 
table(s) in the library. 

Modification of a program's measurement table would likely 
be logged as a significant data processing event. If the 
data bank update was accomplished online, the keyboard 
operator would be notified of the results of the update 
by an appropriate output message indicating program name 
and the function designator(s) that underwent change. Such 
changes could be introduced into an online and operational 
system in a convenient and timely manner - the concept of 
introducing an expedient temporary hardware change or over- 
ride that is destined to remain in effect for a short 
duration {say, a manner of hours) and then reverting to a 
normal system configuration becomes an attractive and 
practical possibility. A crude estimate of the time re- 
quired to accomplish a data bank update appears in the 
following example: 

Let: P = 100 = Total number of test programs in 

the current online program library 

R = 10 = Average number of DASD read operations 
required to completely access a mea- 
surements table for a single program 

M = 50/i = Percentage of programs whose measurement 
tables will require modification due to 
recent measurement addressing change 

W = 3 = Average number of rewrite operations 

required for those tables to be modified 

T = 8 = Average number of read/write operations 
that can be accomplished per second on 
the DASD used for the measurement table 
library 

Negligible computer central procesor time required for 
all operations involved in the measurement table update 



b-b 



Then; 



Total time required for 

measurements table = P R + P W x M 

library update (seconds) T T TOO 

= 100(10) + 100(3) X 50 
_^ -^-/ ,^ 

= 143.75 Seconds 



5-9 



APPENDIX A 
THE DATA BANK FILE DESIGN 



A. INTRODUCTION 

Within this Appendix are indicated the criteria which evolved into the 
functional design of the data bank file of the first GOAL compiler 
Implementation. Although the original implementation utilized IBM 
Direct Access Storage Devices (DASD) and support software, it 1s felt 
that the file design could be successfully transcribed to the DASD of 
other manufacturers. Specifically, the file design relies on no fea- 
tures that are found only on IBM DASD or support software. In general, 
the following functional DASD capabilities must be present to support 
the current data bank design: 

The DASD must be capable of supporting a data set 
organization of fixed length logical records. 

Random read and write access to any one of the (n) 
records within a data set of (n) total records must 
be possible by specifying the relative record number 
utilizing the first record of the data set as the 
origin. With the additional requirement of fixed 
length logical records, the absolute address of a 
given record can be easily determined by knowing the 
relative record position. 

To accomplish data bank maintenance in the same fashion 
as that of the current IBM implementation, a general 
purpose sort utility program is required. If in another 
system such a program Is not available or feasible, 
adequate computer storage must be available to accomplish 
the sort operation in a memory resident fashion. 

A.l GENERAL FILE DESIGN 

The records of any file must be logically organized such that they can be 
inserted or retrieved for processing. In the selection of a certain file 
structure, all of the following are to be considered: 

File Creation - separate program(s) must usually be 
developed to Initialize the first copy of a file. 
Thereafter, a revised or new copy of the file is 
created by update of an existing version. The GOAL 
data bank requires a special initialization program 
to prepare the DASD storage before records can be 
inserted. 



A-1 



File Use - Usually, a given file application will 

dictate that the file be usable either to read records 
from or to write into. The data bank application 
requires both read and write capability within the 
same program. 

File Maintenance - Very few files can be envisioned 
that will not require either periodic or sporadic 
maintenance. The term "maintenance" Is generally 
construed to mean the addition, replacement, changing, 
or deletion of records. The data set design will in 
some ways dictate and other ways be constrained by the 
maintenance techniques or requirements. In the case 
of the data bank, the existence of a sort utility program 
makes directory maintenance immensely easier. 

File Backup - This may be as simple a process as copying 
the file on to another medium (magnetic tape Is popular 
for this usage) to enable partial or complete recovery 
from an unforeseen disaster to the file prime copy. The 
GOAL data bank system has been structured such that the 
directory data set can be completely destroyed and 
successfully recovered using the contents of the data 
bank set alone. The data bank data set must be backed 
up by copy to another medium such as tape. As this 
time, no specific software modules have been provided 
to effect these recoveries. 

A. 2 DATA FILE CHARACTERISTICS 

The following inherent characteristics form the basis for selecting an 
efficient method of file organization: 

Size - A file so large that it cannot be all online 
{available to the system) at one time dictates very 
specific organization and processing techniques. The 
data bank was designed with the intent of having all 
of the file online, but resident on DASD. Generally, 
only one record at a time will be of interest 1n data 
bank utilization. These records must be randomly 
accessible. 

Growth Potential - It was convenient to size the original 
data bank at a capacity (8000 entries) considerably above 
that currently being used (approximately 2000 entries). 
Thus, the data bank may expand significantly without 
requiring an overall size increase of the data set. If 
and when an increase in overall capacity is required, 
this can be accomnodated with modest effort within the 
framework of the original data bank design. The original 
data bank support and maintenance modules were written 



A-2 



in FORTRAN - because of FORTRAN language constraints, 
a data bank resizing will require changes to the 
declarations section of several modules. Except at 
very infrequent intervals, it is considered unlikely 
that resizing will be required; the inconveniences 
resulting from these software changes were not there- 
fore, considered prohibitive. 

Activity - In regards the amount of activity, an inactive 
file may be referred to so infrequently that the particular 
file structure or processing technique chosen does not matter. 
The GOAL data bank is considered a file which typifies the 
other extreme, i.e., an active file to be heavily used by 
the GOAL compiler. The file structure was chosen carefully 
to avoid an inordinate amount of time searching for desired 
records . 

The percentage of activity is also a factor of consideration. 
The data bank is an application which requires retrieval of 
only a low percentage of the available records in a file 
during an average processing run. This use implies a random 
type organization such that any record can be located con- 
veniently without having to scan all or a large number of 
other records In the file. In the GOAL data bank each 
record may be essentially considered an independent data 
entity having no relationship {physical or logical) with 
any other record of the file. 

In some instances the activity distribution can be a file 
design factor. If some group of records are more frequently 
significant than others, some method of locating these 
records is in order so that they can be effectively fetched. 
The Data Bank Reference Records in the GOAL data bank are an 
example of records of this type; they have been located in 
a fixed specific area within the file so that they can be 
efficiently searched and processed, 

A. 3 FILE PROCESSING CHARACTERISTICS 

The usage of a file usually dictates the type of processing In which the 
file will be involved. Sequential processing of a file implies that the 
records will be processed in a monotonically Increasing or decreasing 
sequence. A deck of cards or magnetic tape is ideally suited to this 
application type. To be effective, the records of a sequentially 
processed file must be sorted according to the sequence to be followed 
in processing. The records are then written in a physically contiguous 
fashion in the file. Thus, the next record to be processed is always 
immediately adjacent to the current record. Although sequential processing 
can be extremely rapid in many applications, its use demands that all input 
transactions be batched (collected) and sorted to the same physical key 
sequence as the file before processing. 



A-3 



Random processing allows (or, rather, requires) that all records of the 
file be accessible and writeable in a random order. No collection or 
sorting of input transactions is required before processing. The same 
could be said of the records within the file itself, i.e., there is no 
required record sort sequence or rules concerning which records need be 
physically adjacent. The GOAL compiler requires access to the data bank 
in a strictly random manner; the actual method chosen for implementing 
the data bank allows sequential processing also. 

A. 4 DATA BANK CONTENTS 

GOAL compiler support was the prime function of the data bank in the first 
implementation of the GOAL language. This encompasses data records of 
the following type: 

Function Designators - In almost all instances, a 
function designator record contains sensor-base 
hardware data such as measurement type (discrete/ 
analog, input/output, etc.) and physical hardware 
addresses. 

Note - The term "function designator" is used 
within the GOAL language for purposes 
other than symbolic names for sensor- 
based measurements. 

GOAL Subroutine References - These records provide 
abbreviated system dependent names for GOAL sub- 
routines. 

GOAL Macros - These records contain user-written 
and system macros to be used as writer aides during 
compilation of a GOAL test program. 

The functional design presented in Appendix B indicates a few other record 
types in the data bank file used for file structuring and searching aids. 
Most (possibly, 99+%) of the data bank file records will be function 
designator records. A direct access (random) file structure for relative 
record retrieval must contain fixed length logical records. Since the 
file contains records of varying data context, the fixed record length 
must be large enough to accommodate all of the data of the largest record 
type. 

Records of other tyoes will then utilize only a portion (and, consequently, 
waste the remainder) of the total record capacity. Fortunately, the record 
type requiring the largest record capacity was the function designator type; 
total waste space will therefore be minimized in the file. An individual 
function designator will require only one data record for Its description. 
A GOAL subroutine will require only one record for its name reference. A 
macro will require two or more records. 



A-4 



A. 5 DATA BANK USAGE 

The GOAL language stipulates that each function designator, macro, or 
subroutine Is identified by a unique 1 - 32 character symbolic name. 
The GOAL compiler queries the data bank providing only this 1 - 32 
character name. Using this name as a search argument (record key), the 
data bank software must either locate and retrieve the required record 
or signify that a record associated with the supplied key does not exist 
within the data bank. 

Features of the GOAL language also require that a number of uniquely named 
'data banks' is resident in one data bank file. 



A-t) 



APPENDIX B 
THE DATA BANK FUNCTIONAL DESIGN 



B . INTRODUCTION 

Within this Appendix is presented a functional description of the data 
bank design as implemented for use by the initial version of the GOAL 
compiler. 

B.l BASIC SPECIFICATIONS 

The principal functions of the tiOAL data bank are outlined in the following: 

The data bank shall provide for the storage and retrieval 
of uniquely named GOAL function aesignator records, macro 
records, and subroutine reference records. 

Function designator, macro, and subroutine records are to 
be individually retrievable by specifying: (1) the name 
of the aata bank in which the record is assumed to reside, 
and; (2) the unique record name. Record names are assumed 
to be unique only within the bounas of the specific data 
bank in which they are found, e.g., the record called A 
can be the only record with that name within the data bank 
in which it is found. There can be, for instance, a record 
A within a data bank called X; another record A can exist 
in data bank Y, etc. 

The data bank system shall provide a file organization 
capable of supporting and selectively using several 
uniquely named independent data banks. The total number 
of data banks to be supported at any one time shall be 
selectable at file initialization time. Provision has 
been made to allow increase of the number of allowed data 
banks after file initialization without requiring complete 
reinitialization of the system; utility software has not 
been provided to accomplish this extension at this time. 

B.2 GENERAL APPROACH 

The data bank will be a disk resident file constructed primarily for random 
(non-sequential) processing.** The file structure is to support random access 
to any uniquely named record (member) by supplying the record's symbolic name 
(record key). To support this operation, two disk resident data sets will be 
required. One will be referred to as the "data bank," "data bank file," or 



**The file structure chosen allows for sequential as well as random processing. 



6-1 



"data file." This data set will contain the GOAL function designator, 
macro, and subroutine records. The second data set will be deemed the 
"data bank directory," or "directory." The directory will contain an 
index to all named records in the data bank. Each index entry will 
consist of the record name, an indication of the uniquely named data 
bank in which the record logically resides, and the relative record 
position of the record within the data bank data set. All of the index 
entries within the directory shall be sorted in a manner that is 
conducive to efficient search. 

The operational concept of the data bank Is analogous in e'^ery way except 
physical record layout to the technique required to use an everyday 
telephone directory. The telephone number and address are the data 
records of the telephone directory; the names are the record keys. If 
one is to conduct an efficient search through so large an assortment of 
keys, the keys must be placed in a physical structure in such a way that 
some type of search is strategically possible. For alphanumeric keys 
(such as human names or data bank record names), sorting the keys into 
alphanumeric collating sequence is a method which allows effective human 
or machine search. 

Figure B-1 illustrates the functional relationship between the distinct 
elements of the data bank system. In the data bank design, the data portion 
of the file 1s resident In the data bank data set while the sorted grouping 
of record keys is to be found In a distinct data set called the directory. 
Accompanying each key in the directory is the record location (in the data 
bank) where the data associated with that key is to be found. This split 
arrangement of keys in one data set and data in another has four distinct 
maintenance advantages over the combined record technique of the telephone 
book, to wit: 

The directory must be in sorted key sequence for search 

reasons. When maintenance decrees the addition or deletion 
of records, the directory must be re-sorted to accommodate 
the new keys and to eliminate the old. It is to be noted 
that the keys must be sorted to accomplish this aim - there 
is no requirement that the data be rearranged in any manner. 
By involving only the contents of the data bank directory in 
the maintenance key sort operation, the speed at which both 
the sort and the directory data set reconstruction can be 
accomplished is significantly enhanced. 

With distinct directory and data bank data sets a larger 

number of keys can be present in a given size of record than 
would be possible if both keys and data were present in the 
Scune size record. The speed at which the directory search 
can be accomplished will be almost wholly dependent on how 
many input operations are required to fetch records contain- 
ing keys. 



B-Z 



If a small number of keys are present in each record, 
then many records may be required, etc. A crude analogy 
exists in the example of the telephone directory - if the 
current directory page size were increased to newspaper 
size sheets, one would have to turn fewer pages to find a 
given key. In contrast, if the telephone directory were 
reprinted on 3 x 5 cards, a great deal of page turning 
would be required. 

Although the directory must be maintained in sorted order, 
there is no reason why the effort must be expended to 
maintain a sorted data bank file {containing the data). 
Put in another way, the data records, once entered into 
the data bank, need never be reshuffled to accommodate 
new or deleted records. This feature leads to a signifi- 
cant savings in maintenance time. As an illustration to 
the contrary, consider the maintenance required for a non- 
random sequentially organized data set, e.g., a magnetic 
tape. The time spent in reshuffling (recopying) the entire 
data set to accommodate one record addition/ deletion/change 
could comprise 99.99% of the total maintenance time. This 
disproportionate time mix degrades even further as the data 
set size increases. 

By avoiding a reshuffle operation on record addition/ deletion 
in the case of the data bank file, it was possible to adopt 
a scheme for effectively reclaiming the space vacated by 
deleted records. Once a record has been deleted, the record 
position becomes available for use in adding a new record in 
a subsequent maintenance run. During data bank initialization, 
all free records are chained together to form what is referred 
to as the "free record queue," i.e., all record spaces avail- 
able for use. When a record is to be added to the file, the 
first available record on the free queue is removed from the 
chain and used for the addition. When a record is deleted, 
the record space is reinserted to the head of the free queue 
chain, thus making the space reusable. 

B.3 GENERAL DIRECTORY STRUCTURE 

The illustration of Figure B-1 depicts the directory as a single table con- 
taining one entry for each record in the data bank. Such a directory that 
contains (n) entries for (n) record references is deemed an "inverted" 
directory. If it were possible for the table to be totally memory resident 
at use or maintenance time, access to any record of the file would proceed 
at maximum speed - a simple memory table search followed by one I/O read 



B-3 



would be required. Unfortunately, such a single-level table becomes 
prohibitively large even for a relatively modest size data bank file. 
It must therefore be broken into segments of a size such that any one 
can be conveniently contained in computer memory. 

Figure B-2 indicates an example of a directory that has been structured 
into a series of blocks ("directory blocks" or "directory records") in 
two levels. In general, two types of blocks are present - one "master" 
block and several "lower level" blocks. The lower level blocks accumu- 
latively represent the single inverted directory table broken into 
segments of a more practical size. Each individual entry in a lower- 
level block consists of a record name and a pointer (record number) to 
that record in the data bank file. If the directory contained only lower- 
level blocks, any one of which could be memory- resident at a given time, 
then a block-by-block serial search would be required to locate a record 
in the directory. Access of any one directory block would require one I/O 
read operation. As a method of eliminating the serial search and thus 
enhancing overall directory search speed, a master directory block has been 
introduced as shown in Figure B-2. This block indicates the contents of 
all of the lower-level blocks of the directory. Each master block entry 
points to a lower block and indicates the highest (in collating sequence) 
named entry in that block. If the master block can be made memory- re si dent, 
a search for a given record proceeds as follows: 

1. Via the master block, determine the lower-level block which 
must contain the sought none. In the example of Figure B-2, 

a name "D" must be contained in block 3 since block 2 contains 
as the highest entry "B", and block 3 as the highest entry "G". 

2. Access the required lower- level block. 

3. Search the lower- level block for the required name. 

4. After finding the directory entry containing the record name 
in the lower-level block, use the record number portion of 
the entry to fetch the sought record from the data bank file. 

The above process requires only two I/O read operations to find and retrieve 
any given named record from the data bank file; note that the assumption has 
been made in this instance that the master block was memory- resident before 
the search started. 

Since the directory itself is a direct-access (randomly organized) data set, 
it will be significantly easier to manipulate if all records (blocks) are of 
constant or fixed record length. This results in a "balanced" directory - 
each block contains a constant number of directory entries. The unbalanced 
directory of Figure B-2 has been rearranged to a balanced form in Figure B-3. 



b-4 



The "directory blocking factor" (N), i.e., the total and constant number 
of directory entries possible per directory block, for this illustration is 
four (4). Note that for a two-level balanced directory there will always be 
(N) blocks at the lowest level; this then implies the following size 
relationships; 

Given a directory blocking factor (N); 

Total number of blocks 

in the directory data set = N + 1 

Directory block size (words 

or bytes) = N x (Directory entry size in 

words or bytes) 

= the amount of computer memory that 
must be present for one directory 
block 

Total number of named records 
that can be referenced in the 
directory = N 

Using the above as a basis for determining directory blocksize, assume that a 
data bank to support a total of 8,000 entries is required; 

Let (N) = 90 

Total entries supported = N^ = 8,100 

Directory blocksize = N x (directory entry size) 

= 90 X 7b (current implementation 
directory entry size) 

= 6,840 bytes 

The directory blocksize in the above instance has grown to a \/ery large entity- 
requiring a large memory block for support. If the master block is to remain 
memory- resident, and the lower-level blocks retrieved as required one-at-a-time, 
a total of 13,680 bytes of computer memory would be required to support 
directory operations alone. This is considered a severe cost to service a data 
bank file of 8,000 records. The eventual size of the operational GOAL data 
bank could run as high as 30,000 to 100,000 entries. A two-level directory to 
support such a sizeable data bank would require directory blocks of enormous 
capacity. 

The solution selected to obviate the above sizing problem is illustrated In 
Figure B-4. Here, the two-level directory has been expanded vertically into 
a three-level balanced version. Figure B-5 represents a tabular comparison 



b-b 



of the size potentials between two- level and three- level directories. The 
calculations are related to an IBM 2314 disk unit which supports a total 
track capacity of 7,294 bytes (data plus inter-record gaps, as required). 
The directory blocking factor (N) was considered in the range of 10 to 50 
entries per block - this upper limit will support a data bank of 125,000 
entries with a three-level directory. 

B.4 GENERAL CONTENTS OF DIRECTORY RECORDS 

Figures B-6 and B-7 depict the layout of the master, upper-level, and the 
lower-level directory blocks. Each block is seen to be composed of a block 
header and (N) directory entries. The block header indicates: 

the record (block) number in the directory file 

the total number of entries possible in the block (N) 

the total number of directory entries currently in use in the 
block 

Each directory entry is seen to contain: 

A delete field - used during maintenance to delete reference 
to an existing record 

A record name - consisting of a data bank reference number 
and a 1-32 alphanumeric character symbolic name 

A pointer to another record (record number) either in the 
directory data set (master and upper-level blocks) or to 
the data bank file (lower-level blocks only) 

As indicated above, the total record name contains two significant portions - 
the data bank reference number and the proper alphanumeric name. Each uniquely 
named data bank is assigned a unique reference number when the data bank is 
originally created. This reference number becomes the first 32 bits of the 
names of all records contained within that data bank. The data bank reference 
number is actually the record number of the applicable Data Bank Reference 
Record in the data bank file. 

Figure B-8 indicates pictorial ly the relative positioning of all blocks to be 
found in the directory data set. The actual block numbering scheme and order 
of loading is indicated in Figure B-9. 

B.5 DATA BANK FILE CONTENTS 

Figures B-10 and B-11 tabul arize the general record types and contents of the 
records to be found in the data bank file. The relative positioning of the 
records within the file was indicated in Figure B-8. All data bank records are 
fixed in length and each contains a header followed by a data segment. 

B-b 



B.5.1 Data Bank Capcity Record 

This record is the first record of the file. The data bank Initialization 
program composes this record in accordance with control card input when the 
data bank file is first established. Figure D-1 indicates the initialization 
action. Only a portion of the header and none of the data portion is used in 
this record type. A brief description of the field contents is given below; 
the exact record format is to be found in Appendix E. 

Record Number - This record is located first in the file so 
that the use and maintenance modules can find it without search. 

Total number of Records Available (RAVAIL) - This is the total 
number of record spaces which were allocated for the data bank 
file when it was originally created. This value is established 
during initialization (read from a control card). 

Total Number of Records Still Unused (FQTOT) - This field represents 
the total number of records remaining on the Free Queue for use in 
adding new records to the data bank. This is initialized to the 
total number of records reserved for the entire file minus those used 
for the capacity record and the data bank reference records. 
Symbolically: 

FQTOT = RAVAIL - (D3MAX + 1) 

Pointer to Head of Free Queue (FQPTR) - A field indicating the first 
record available for allocation in the data bank. The next time that 
a new record is added, the record at the head of the Free Queue is 
used. This field is initialized to point to the first record beyond 
the data bank reference records in this file. Symbolically: 

FQPTR = DBMAX + 2 

Maximum Number of Allowed Data Banks (DBMAX) - This is the total number 
of uniquely named data banks that will be allowed to exist. DBMAX is 
initialized to the amount read in via control card during initialization 
plus one more to allot for a mandatory data bank called "SYSTEM." This 
SYSTEM data bank will become a part of the system at initialization time. 

Total number of Data Banks Now in Use (DBCUR) - This field reflects 
how many data banks are currently being used. The value is initialized 
to one (1) - to account for the mandatory SYSTEM data bank. 

Directory Blocking Factor (DBF) - This value has been hardcoded into the 
data bank initialization program and is set at 20 for the current 
implementation. A change of this value will dictate several changes to 
different program modules - discussion of these changes is covered in 
this document, Appendix C. 



B-7 



B.5.2 Data Bank Reference Records 

These records follow the capacity record in the data bank file. One 
reference record exists per allowed data bank - the user specifies via 
control card during data bank initialization as to the total desired. A 
factor of thirty (30) will be used for the original implementation. The 
first data bank reference record (record number 2) will be initialized for 
the data bank called "SYSTEM." All other reference records are initialized 
to the unused state and will remain so until data bank(s} are established 
during normal maintenance. A detailed discussion of the record fields is 
given in Appendix E. A brief coverage of the general contents is below: 

Record Number - This set of records appears in the data bank 
starting at record position number 2. The data bank called 
SYSTEM will be initialized at record position 2. Record positions 
will be assigned to subsequently established data banks on a first- 
come, first- serve basis. 

Forward Chain - All data bank reference records will be chained 
together at initialization time. This chain provides an efficient 
method of serial search to determine if a given data bank exists 
or not. Also, when adding a new data bank reference, the chain is 
followed until an unused reference record is located. 

Type Field - All but the type field associated with the reference 
record for the mandatory SYSTEM data bank will be initialized to 
one (1), which implies the record is unused and free for use. When 
maintenance requires the addition of a new data bank, the reference 
record chain is followed until a vacant (type =1} record is located; 
this record position will then be used for the new data bank. 

Maximum Number of Allowed Data Banks ~ Established during file 
initialization. 

Data Bank Number - The data bank reference numbers are established 
during initialization to be equal to the record numbers in which 
the fields appear. Each named data bank Is referenced by the user 
via a symbolic (alphanumeric) name. Within the data bank software, 
all references to data banks are made by use of data bank reference 
numbers. This number becomes a portion (the leading 32 bits) of 
each record name in the system that "belongs to" or is associated 
with that data bank. 

Data Bank Name - The 1-32 alphanumeric character data bank name. 
The first character must be a letter. 

Revision Label - This field is optional with any given data bank. 
If present, it is a 1-32 character name. If the revision label is 
not used In a given record, this field will be totally blank. 



b-y 



B.5.3 Other Data Bank File Record Types 

Table B-12 tabul arizes the functional contents of all record types to be 
found in the data bank file. Data Bank Reference records have already been 
discussed. The remaining record types consist, in general, of a header and 
a data area. Function Designator and Subroutine Name records will always 
occur singularly - accordingly, the header (see Figure B-ll) for these types 
will be consistent in format as indicated in the following: 

Record Number - As required 

Forward Chain - Always null (zero) 

Type Field - See Table B-12; as required 

Total Number of Records This Chain - Always one (1) 

Pointer to Last Record, This Chain - Always points to this record 
number (the record containing the field) 

Data Bank Number and Record Name Fields - Always used 

Print Expansion - One to 32 character name; record name as it is to 
appear on compiler listings; this may or may not be the same as the 
record name field 

Data Portion - Used as required for record type; Appendix E indicates 
an exact record description. 

Macros will be represented in the data bank file by a Macro Header record 
followed by one or more Macro Skeleton records. The records pertaining to 
one macro will be linked via their respective forward chain fields. Figure 
B-11 indicates that the header of the Macro Skeleton records is abbreviated 
from the type normally found on other record types. The macro skeleton card 
image occupies a portion of the header as well as all of the normal data 
segment. The maintenance processing program will scan each macro skeleton 
card, locate each occurrence of a formal parameter, and replace each occurrence 
with the following character sequence: 

1st Character = '& (ampersand) 

2nd Character = Single digit, 1-0, representing formal parameters 

one through 10, inclusive 

3rd Character = « (ampersand) 

4th through 

Next to Last = & (ampersand) 

Last Character = Blank 

A maximum of ten (10) formal parameters will be allowed for any given macro 
in the current implementation. 

b-9 



o 



,<i- 



<- 



"THE DATA BANK' 



->f 



DATA BANK DIRECTORY 



Record 
Name 



ALPHA 



BETA 



DELTA 



GAMMA 



Record 
Location 



4213 



10 



11 



7211 



^ 



DATA BANK FILE 



Record 
Location 



10 
11 



4213 



7211 



Beta Record 
Delta Record 



Alpha Record 



Gamma Record 




^^ 



Figure B-1. FUNCTIONAL RELATIONSHIP OF DATA BANK ELEMENTS 



Block 1 



SIMPLIFIED TWO-LEVEL INVERTED 
DIRECTORY ~ 



f TYPICAL LOWER-LEVEL BLOCK ENTRY 



Databank 

Record 

Name 



Pointer (Record 
Number to the 
Databank file 



/ 



/ 



/ 



B 


2 


G 


3 


K 


4 


M 


5 


T 


6 


X 


7 



Block 


2 




BlVk 3 


/ 


Bloc 


k 4 


A 


B 




D 


G 




J 


K 



DIRECTORY MASTER 
BLOCK 






Highest 
(Col 1 ating 

Sequence) 
Record Name 



Pointer (Block 
Number) to one of 
the lower level 
Directory Blocks 



TYPICAL MASTER BLOCK ENTRY 



Block 


5 




Block 


6 




Bloc 


k 7 


L 


M 




Q 


T 




W 


X 



Figure B-2. 



ILLUSTRATION OF TWO-LEVEL 
BALANCED DIRECTORY 



I 



TTT 



(N) 
Entri es 



_^ 



Block 1 



G 


2 


M 


3 


X 


4 


N/U 


N/U 



DIRECTORY MASTER 
BLOCK 



(N) = Directory Blocking Factor; 
total number of directory 
entries per directory block 



N/U" = Not Used At Present; 

Available for Future Use 



Block 2 



Block 3 



Block 4 



Block 5 



. A 


** 


B 




D 




G 





J 




K 




L 




M 





"TfT 



(N) 
Entries 



^ 



Q 




T 




W 




X 





N/U 




N/U 




N/U 




N/U 


1 



** Pointers to Databank File Omitted 
in this Illustration 



Figure B-3. 



or 

t 



CO 



MASTER 
BLOCK 




(3) (4) 



(n) (12) 



(7) 
Directory Blocking Factor = N 

Maximum # Databank Member Names = H =27 (Only 20 used in this example) 
Total # Directory Blocks Required = (N)^ + (N) +1 = 13 in this example 
Directory Block (Record) Numbers Shown in Parenthesis Above 



3 in this example 
,3 



(N) 

UPPER 
LEVEL 
BLOCKS 



LOWER 
LEVEL 
BLOCKS 



Figure B-4. SAMPLE DATABANK DIRECTORY SHOWING BLOCK STRUCTURE 



*** ASSUMING 7&-BITE DIRECTORY EiiTRY SIZE 
***BLOCKSIZE IIJCLUDES 12-BYTE HEADER 



*= 







BLOCK 


WASTE 


* 






PER 


PER 


TOTAL 


/¦/ 


BLOCKSIZE 


TRACK 


TRACK 


ENTRIE 


10 


772 


8 


1118 


100 


11 


848 


7 


1358 


121 


12 


924 


5 


17 50 


144 


13 


1000 


6 


1294 


159 


m 


107G 


6 


838 


196 


15 


1152 


5 


1534 


225 


15 


1228 


5 


1154 


256 


17 


1304 


5 


7 74 


28 9 


18 


1380 


4 


1774 


324 


19 


145G 


4 


14 70 


361 


20 


1532 


4 


1166 


400 


21 


1506 


4 


862 


441 


22 


16(14 


4 


558 


404 


23 


1760 


3 


2014 


529 


24 


183C 


3 


1785 


576 


25 


1912 


3 


1558 


525 


26 


1988 


3 


1330 


675 


27 


2054 


3 


1102 


7 29 


28 


2140 


3 


874 


7 84 


29 


2216 


3 


646 


841 


30 


2292 


3 


418 


900 


31 


2368 


2 


2558 


961 


32 


2444 


2 


2406 


1024 


33 


2520 


2 


2 2 54 


1089 


34 


259G 


2 


2102 


1156 


35 


2 67 2 


2 


1950 


1225 


36 


27 48 


2 


17 9 


1296 


37 


2824 


2 


1G4G 


13 59 


38 


29 


2 


1 4 9 4 


1444 


39 


2 97 G 


2 


1342 


1521 



*********** 2 -LEVEL ********** 
* * 

TOTAL TOTAL * 

DIRECTORY SPACE 

BLOCKS ALLOCATION 



*********** 3-LEVEL ********** 

* * 

* TOTAL TOTAL * 
TOTAL DIRECTORY SPACE 

ENTRIES BLOCKS ALLOCATION 



11 


2 


12 


2 


13 


3 


14 


3 


15 


3 


16 


4 


17 


4 


18 


4 


19 


5 


20 


5 


21 


6 


22 


G 


23 


6 


24 


e 


25 


9 


25 


9 


27 


9 


28 


10 


29 


10 


30 


10 


31 


11 


32 


16 


33 


17 


34 


17 


35 


18 


36 


IS 


37 


19 


38 


19 


39 


20 


40 


20 


Figure B-5. 


(1 Of 



1000 
1331 
1728 
2197 

2744 

3375 

4095 

4913 

5832 

6859 

8000 

9261 

10648 

12167 

13824 

15525 

17576 

19683 

21952 

24389 

27000 

29791 

32768 

35937 

39304 

42875 

4 6 6 5 6 

50G53 

54872 

59319 



111 

133 
157 
183 

211 
241 

273 

30 7 

343 

3 81 

421 

463 

507 

553 

601 

651 

703 

757 

81 3 

871 

931 

993 

1057 

1123 

1191 

1261 

1333 

1407 

1483 

1561 



14 

19 

27 

31 

36 

49 

55 

62 

86 

96 

106 

116 

127 

185 

201 

217 

235 

2 5 3. 

271 

291 

311 

497 

529 

562 

59G 

631 

657 

704 

742 

781 



***ASSUMIUG lb-BYTE DIRECTORY ENTRY SIZE 
***BLOCKSIZE li'^CLUDES 12-BYTE HEADER 



* 4r * * * * * ** * * 

* 



2- LEVEL 



N 

40 
41 
42 
43 
44 
45 
4G 
47 
48 
49 
50 



ULOCKSIZE 

3052 
312 8 
3204 
3280 
3350 
3432 
3508 
3584 
3560 
373G 
3812 



BLOCK 

PER 
TRA CK 

2 
2 
2 
2 
2 
2 
2 
1 
1 
1 
1 



WASTE 

PER 
TRACK 

1190 

1038 

88 6 

734 

582 

430 

270 

3710 

3634 

3558 

3482 



TOTAL 
ENTRIES 

1600 
1681 
1764 
1849 
19 36 
2025 
211G 
2209 
2304 
2401 
2500 



TOTAL 
DIRECTORY 
BLOCKS 

41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 



********** 
* 
TOTAL * 
SPACE 

ALLOCATION 

21 
21 
22 

22 
23 
23 
24 
48 
49 
50 
51 



*********** Z- LEV EL ********** 

* * 

* TOTAL TOTAL * 
TOTAL DIRECTORY SPACE 

ENTRIES BLOCKS ALLOCATION 



64000 
68921 

74088 

79507 

85184 

91125 

97336 

103823 

110 5 9 2 

117649 

125000 



1641 
1723 
1807 
1 893 
1981 
2071 
2153 
2257 
2353 
2451 
2551 



821 

862 

904 

947 

991 

103G 

1082 

2257 

2353 

2451 

2551 



Figure B-b. (2 of 2) 



I 



^ 



(N) Individual Directory Entries Per Block 



BLOCK HEADER 



DIRECTORY 
ENTRY # 1 



\ 



X 



TYPICAL BLOCK HEADER FOR \ 
.MASTER (RECORD #1) AND . ^ 
fUPPER-LEVEL BLOCKS 



Block 

(Record) 

Number 



Total # 
Entries 
Possible in 
this Block 



Total # 
Entries now 
in Use in 
this Block 



^— Header Length = 12 Bytes 



^ 



DIRECTORY 

ENTRY # 2 



/ 




-^ 



DIRECTORY 
ENTRY # (N) 



^ 



^ 



A TYPICAL DIRECTORY ENTRY FOR MASTER 
OR UPPER-LEVEL BLOCKS 



(N) = Directory Blocking 
Factor 



Pointer (Block #) 
to Block at Next 
Lower Level 



Delete 
Field 



Databank 

Reference 

Number 



Search Key 
(Member 
Name) 
(32-Chars) 



Length of Individual Entry = 76 Bytes 



M 



Figure B-6. DATABANK DIRECTORY: MASTER AND UPPER-LEVEL BLOCK LAYOUT 



CD 



e 



(N) Individual Directory Entrsjes Per Block 



BLOCK HEADER 



ENTRY # 1 



ENTRY # 2 



\ 



\ 



\ 



\ 



Block 
(Record) 
Number 



Total # 
Entries 
Possible 1 
this Bl ock 



Total # 
Entries novj 
in Use in 
this Block 



^Header Length = 12 Bytes 



^ 



y 




¦> 



y 



X 



X 



X 



X 



ENTRY # (N) 



(N) = Directory Blocking 
Factor 



Pointer (Record #) 
to Member Record 
in Databank File 



Delete 
Field 



Databank 
Reference 

Number 



Search Key 
(Member Name) 

(32-Chars) 



^ 



Length of Individual Entry = 76 Bytes 



^ 



Figure B-7. DATABANK DIRECTORY; LOWER-LEVEL BLOCK LAYOUT 



Record #1 



Master 
Block 



i 



00 



(N) Upper-Level Directory 

Blocks 
(N) Lower-Level Directory 
Blocks 



DATABANK 
DIRECTORY 



N = Directory Blocking Factor = 20 in Release Version 
Record Size = FIXED = (N) x {Directory Entry Size) + 12 

= (20) X (76) + 12 = 1.532 Bytes in Release Version 



Record #1 



Databank 
Capaci ty 
Record 



(M) Databank Name 
Reference 

Records 



(N) 



(M+1) 



Individual 

Member 

Records 



DATABANK 
FILE 



M = Total # Allowed Individual Databanks = 30 in Release Version 
Record Size = FIXED = 172 Bytes 



Figure B-8. PICTORIAL LAYOUT OF DATABANK FILE AND DIRECTORY 



(N) LOWER- 
BLOCKS 



LEVEL 



Record #1 Rec #2 



(N) LOWER-LEVEL 
BLOCKS 



Master 
Block 



Fi rst 

Upper 
Block 

= UB#1 



UB#1 I 



1 I 



CO 
I 



IJD 



Records # 

(UB#1 ) + 1 to 
(UB#1 ) + (N), 
Inclusive — - — 



A 



Record # UB#2 



Second 
Upper 
Block 

= UB#2 



A 



UB#1 + N + 1 



Records # {UB#2) + 1 to 
(UB#2) + (N) , 
I ncl usi ve 



(N) LOWER-LEVEL 
BLOCKS 




A 



DATABANK 
DIRECTORS 



(N) 



Directory Blocking Factor 



Figure B-9, DATABANK DIRECTORY: BLOCK NUMBERING ALGORITHM 



[MACRO] 



f 



Header 



MACRO 
Name 



Total # 

Formal 

Parameters 



Header 




Skeleton Card Image 
(80 Chars) 



...{as many Skeleton Card Records as required) 



Header 



Skeleton Card Image 
(80 Chars) 



[SUBROUTINE] 



Header 


GOAL 
Subrouti ne 

Name 


FORTRAN 
Subrouti ne 
Name 



[FUNCTION- 
DESIGNATOR] 



Header 


FD 
Name 


Print 
Expansion 


FD 
Type 


FD 
Address 



[DATABANK 
REFERENCE 
RECORD] 



Header 



Databank 
Reference 

Number 




[DATABANK 
CAPACITY 
RECORD] 



Header 



Figure B-10. DATABANK FILE: FUNCTIONAL RECORD CONTENTS 



B-20 



DATABANK CAPACITY RECORD 

RAVAIL FQTOT 



FQPTR 



DBMAX 



DBCUR 



DBF 



r 



Record 

# 1 



Total # 
Avai 1 abl e 
Records 



Total # 
Records 
Still 
Unused 



Pointer 
to First 
Record on 

Free 
Queue 



Maximum 
Number 
Al lowed 
Databanks 



Total # 
Databanks 
Currently 
In Use 



Directory 
Blocking 
Factor 



Unused 



DATABANK REFERENCE RECORD 



Record 

# 



Forward 
Chain 



Type = 1 
(Unused) 

Type = 2 
(In Use) 



Maximum 
Number 
Allowed 
Databanks 



Pointer 
to Last 
Databank 
Reference 
Record 



Databank 

# 



Databank 
Name 



Rev-ision 

Label ^ 
(or blank 



) 



Unused 



I 



HEADER OF ALL OTHER RECORD TYPES - EXCEPT MACRO SKELETON RECORD 



Record 

# 



Forward 
Chain 



Type 



Total # 

Records 
on This 
Chain 



Pointer 

to Last 

Record , 

This 

Chain 



Databank 

# 



Record 
Name 



Print 
Expansion 



Data Portion 
of Record 



MACRO SKELETON RECORD 



Record 

# 



Forward 
Chai n 



Type = 5 



Macro Skeleton Card Image 



Figure B-11. GENERAL CONTENTS OF THE HEADER PORTION OF DATABANK RECORDS 



DATA BANK FILE 
GENERAL CONTENTS OF RECORDS 

Type General Contents 

Field Record Description Header Data Portion of Record 

1 Data Bank Reference Hybrid Unused 

(Unused) 

2 Data Bank Reference Hybrid Unused 

(In Use) 

3 Function Designator Standard FD Type 

FD Address or Subroutine Name 

4 Macro Header Standard Total Number of Formal 

Parameters in Macro 

5 Macro Skeleton Hybrid Macro Skeleton Card Image 

6 Subroutine Name Standard Equivalent FORTRAN 

Subroutine Name 

NOTES : (1) Explicit record contents by field are to be 
found described in APPENDIX E 



Figure b-12. 



B-22 



APPENDIX C 

DASD SIZE ESTIMATES FOR GOAL DATA BANK IMPLEMENTATION 

C. INTRODUCTION 

As indicated in Appendix B, the physical storage space required by the data 
bank on external DASD is directly proportional to the blocking factor of the 
data bank directory file. Table C-1 of this Appendix illustrates the total 
DASD space requirements for both the data bank and the directory files in 
terms of directory blocking factor (N). Table C-1 also illustrates the 
implications of using a 2-level versus a 3-level directory structure. The 
relatively ineffective use of DASD storage in the case of a 2-level system 
was the deciding factor that led to the use of a 3-level directory in the 
original GOAL data bank implementation. 

Table C-1 is intended for use as follows: 

1. Determine the total number of named entries to be supported 
in the GOAL data bank. 

2. Find an equal or higher value entry in the "TOTAL ENTRIES" 
column of the 3-level directory section of the table. 

3. From the entry selected in Step 2, the blocking factor (N) 
can be determined. The total amount of IBM 2314 Disk unit 
space {in physical tracks) required to support a data bank 
of the chosen size is indicated on the same line as the 
blocking factor. 

Use of Table C-1 is demonstrated in the following example: 

A data bank is required to support 30,000 named entries. 

The value of closest proximity to 30,000 in the TOTAL 

ENTRIES column of the 3-level directory section is 32,768. 
This corresponds to a blocking factor of 32. 

A data bank and a directory file to support 30,000 (the 

chosen system will actually accommodate up to 32,768) named 
entries will require a total of 1,790 disk tracks. 

For the initial GOAL data bank implementation, a blocking factor of 20 was 
selected in sizing the data bank. This will allow support of a total of 
8,000 named entries and require a total of 414 disk tracks. 

One IBM 2314 disk pack can provide 4,000 data tracks of DASD storage. 
Table C-1 indicates that data banks selected with blocking factors in 
excess of 42 will require that more than one physical disk pack be used. 



C-1 



Table C-1. (1 of 2) 



** khL SIZES IN BYTES 

** {N) = U UMBER OF DIRECTORY ENTRIES PER DIRECTORY BLOCK 



172: DATA BANK PHYSICAL RECORD SIZE 
26: TOTAL DATA BANK RECORDS PER TRACK 
76: DIRECTORY ENTRY SIZE 



N 



************ 2- LEVEL ************* 
* * 

TOTAL DATA DIRECTORY TOTAL 

ENTRIES TRACKS TRACKS TRACKS 



************ 3-LEVEL ************* 
* * 

TOTAL DATA DIRECTORY TOTAL 

ENTRIES TRACKS TRACKS TRACKS 





10 


100 


4 


2 


6 


1000 


39 


14 


53 




11 


121 


5 


2 


7 


1331 


52 


19 


71 




12 


141+ 


6 


3 


9 


1728 


67 


27 


94 




13 


169 


7 


3 


10 


2197 


85 


31 


115 




m 


195 


8 


3 


11 


2744 


106 


36 


142 




15 


225 


9 


4 


13 


3375 


130 


4 9 


179 




15 


256 


10 


4 


14 


4095 


158 


55 


213 




17 


289 


12 


4 


16 


4913 


189 


62 


251 




18 


324 


13 


5 


18 


5832 


225 


86 


311 


c; 


19 


361 


14 


5 


19 


6859 


264 


96 


360 


r\3 


20 


400 


16 


6 


22 


8000 


308 


106 


414 




21 


441 


17 


6 


23 


9261 


357 


115 


473 




22 


484 


19 


6 


25 


10648 


410 


127 


537 




23 


529 


21 


8 


29 


12167 


468 


165 


653 




24 


576 


23 


9 


32 


13824 


532 


201 


733 




25 


625 


25 


9 


34 


15625 


601 


217 


818 




26 


676 


26 


9 


35 


17576 


676 


235 


911 




27 


729 


29 


10 


3 9 


19683 


758 


253 


1011 




28 


784 


31 


10 


41 


21952 


845 


271 


1116 




29 


841 


33 


10 


43 


24389 


939 


291 


1230 




30 


900 


35 


11 


46 


27000 


1039 


311 


1350 




31 


961 


37 


16 


53 


29791 


1146 


497 


1543 




32 


1024 


40 


17 


57 


32768 


1261 


529 


1790 




33 


1089 


42 


17 


59 


35937 


1383 


562 


1945 




3U 


1156 


4 5 


18 


63 


39304 


1512 


596 


2108 




35 


1225 


48 


18 


66 


42875 


1650 


631 


2281 




36 


1206 


50 


19 


69 


46656 


1795 


667 


2462 




37 


1369 


53 


1 9 


72 


50653 


1949 


704 


2653 




38 


1444 


55 


20 


76 


54872 


2111 


742 


2853 




39 


1521 


59 


20 


79 


59319 


2282 


7 SI 


3063 



Table C-1. (2 of 2) 



** ALL SIZES IN BYTES 

** (//) = BlIMBBR OF DIRECTORY ENTRIES PER DIRECTORY BLOCK 



172 
26 
76 



DATA BANK PHYSICAL RECORD SIZE 
TOTAL DATA BANK RECORDS PER TRACK 
DIRECTORY ENTRY SIZE 



************ 2-LEVEL ************* ************ Z-LEVEL ************* 

* * * * 

TOTAL DATA DIRECTORY TOTAL TOTAL DATA DIRECTORY TOTAL 

N ENTRIES TRACKS TRACKS TRACKS ENTRIES TRACKS TRACKS TRACKS 



o 
) 

Co 



HO 


1600 


62 


21 


83 


64000 


2452 


821 


3283 


41 


1681 


55 


21 


86 


68921 


2651 


862 


3513 


42 


1764 


58 


22 


90 


74088 


2850 


904 


3754 


43 


1849 


72 


22 


9 4 


79507 


3058 


947 


4005 


44 


1936 


75 


23 


98 


85184 


3277 


991 


4268 


45 


2025 


78 


23 


101 


91125 


3505 


1036 


4541 


46 


2116 


82 


2 4 


106 


97336 


3744 


1082 


4826 


47 


2209 


85 


48 


133 


103823 


3 994 


2257 


6251 


48 


2304 


89 


49 


138 


110592 


4254 


2353 


6607 


49 


2401 


93 


50 


143 


117649 


4525 


2451 


6976 


50 


2500 


97 


51 


148 


125000 


4808 


2551 


7359 



C.l 



MODIFICATION OF GOAL DATA BANK MAINTENANCE PROGRAMS 



The GOAL data bank maintenance programs were generated using FORTRAN as 
the implementation language. Sizing modifications of data bank capacity 
by altering the directory blocking factor are effected by changes to 
FORTRAN declaration type statements in the maintenance program modules. 
Blocking factor modification must then be extended to the Operating System 
/360 Job Control Language (JCL) statements that govern the physical size 
allocation of the data bank and data bank directory files on disk. 

Table C-2 is a list of the FORTRAN declaration statements that will require 
modification due to blocking factor change. Variables indicated with an 
"N" prefix, e.g., N, Nl , N2, etc., will be replaced with the appropriate 
numeric constants from Table C-4. In all data bank maintenance program 
modules where the declarations appear, they must be so modified and the 
programs recompiled. 

Table C-3 is a list of the Operating System/ 360 JCL statements effected by 
blocking factor change. 

Table C-4 is a tabular list of constants that are to replace the "N" prefix 
variables of Tables C-2 and C-3. Substitution constants are provided for 
blocking factors ranging from 10 to 50. For the relation of blocking factor 
versus total number of supported data bank entries, see Table C-1. 

C.2 FORTRAN DECLARATION STATEMENTS AFFECTED BY DIRECTORY BLOCKING 
FACTOR CHANGES 



The following FORTRAN declaration statements are directly affected by block- 
ing factor modifications within the GOAL data bank directory file. Variables 
that appear below with an "N" prefix, e.g., N, N2, etc., are to be replaced 
with appropriate values from Table C-4. In any data bank maintenance program 
module in which these declarations appear, they must be modified, replaced, 
and the programs recompiled when data bank size changes occur. 



GIVEN:- 



N = Directory Blocking Factor 



INTEGER 
INTEGER 
INTEGER*2 
EQUIVALENCE 

DEFINE FILE 
DEFINE FILE 
DEFINE FILE 
DEFINE FILE 
DEFINE FILE 



DBLOCK ( Nl ) 

ENT ( 2, N ) 

SK { 34. N ) 

{ ENT(1,1), DBL0CK(4) 

{ SK{1,1), DBLOCK( N2 

10 ( N3. 172, L, AVDB 

11 { N4, N5, L, AVOIR 
13 ( N4, N5, L, AVUTL 

18 ( N3, 172, L, AVDB 

19 ( N4, N5. L, AVOIR 



Table C-2. 



C-4 



C.3 OPERATING SYSTEM/360 JOB CONTROL LANGUAGE STATEMENTS FOR GOAL 

DATA BANK CREATION 

The following JCL statements are directly effected by changes to the GOAL 
data bank directory file blocking factor. Names that appear below with an 
"N" prefix, e.g., N, Nl, N2, etc., are to be replaced with appropriate 
constants from Table C-4. The JCL statements are presented in the format 
usually adopted when creating the data bank and the data bank directory 
data sets from scratch. It is to be noted that the IBM 2314 disk pack 
supports 4,000 physical data tracks. A blocking factor (N) of value 42 
(as presented In Table C-1) requires 3,724 tracks total. For blocking 
factors in excess of 42, the JCL statements presented below must reflect 
allocation of the data bank and the data bank directory data sets to two 
(2) or more disk volumes. 



Table C-3. 



//FT 2 OFOOl DD DSN^GOAL .DATAB^ 

// UNIT=SYSDA,BOL=SER=XXXXX^ 

// SPACE= ( 1 72^ (N3}^j CONTIG) , 

// DCB= (RECFM=F, LRECL=1 72 „ BLK£IZE=1 72), 

// DISP= (NEW, CATLG^ DELETE) 

//FTl IFOOl DD DSN=GOAL . DATAD, 

// UNIT=SYSDA, VOL^SER^XXXXXy 

// SFACE= (NS, (m)^, CONTIG) , 

// DCB= (RECFM=F, LRECIr=N5, BLKSIZE=N5)^ 

// DISP=^ (NEW, CATLG, DELETE) 

//FT18F001 DD DSN^GOAL.DATABl^ . 

// UNIT=-SYSDAj, VOL=SEE=XXXXXy 

// SPACED (772, (N3) , , CONTIG) , 

// DCB^(EECFM=F,LBECL^172,BLKSIZE=172), 

// DISP=-- (NEW, CATLG, DELETE) 

//FT19F001 DD DSN=G0AL.DATAD1, 

// UNIT=^SYSDA, VOL=SER=XXXXX_, 

// SPACE= (N5, (N4),, CONTIG) , 

// DCB= (RECFM=F, LRECL=N5, BLKSIZE=N5), 

// DISF^ (NEW, CATLG, DELETE) 



C-b 



C.4 BLOCKING FACTOR CONSTANTS TO BE APPLIED IN THE DECLARATIVES OF 
TABLE C-2 AND THE JOB CONTROL LANGUAGE STATEMENTS OF TABLE C-3 

In the table presented below, (N) is the data bank directory blocking factor. 
The table below covers the same range of blocking factor (range of 10 to 50) 
as that of Table C-1. 

Table C-4. 

N in N2 in n^ N'5 



10 


19 3 


24 


1000 


111 


772 


11 


212 


26 


1331 


133 


846 


12 


231 


28 


1728 


157 


9 24 


13 


250 


30 


2197 


163 


1000 


14 


269 


32 


2744 


211 


107 5 


15 


2B8 


3 4 


3375 


241 


1152 


15 


307 


36 


4096 


27 3 


1228 


17 


32G 


38 


4913 


307 


1304 


18 


345 


40 


5832 


343 


1380 


19 


364 


42 


6859 


381 


1456 


20 


383 


44 


8000 


421 


1532 


21 


402 


46 


9261 


463 


1608 


22 


4 21 


48 


10648 


507 


1684 


23 


440 


50 


12167 


553 


1760 


24 


4 59 


52 


13824 


601 


1836 


25 


478 


54 


15625 


651 


1912 


26 


49 7 


56 


17576 


703 


1988 


27 


516 


50 


19583 


757 


2064 


28 


535 


60 


21952 


813 


2140 


29 


554 


62 


24389 


871 


2216 


30 


573 


64 


27000 


931 


2292 


31 


59 2 


66 


29791 


993 


2368 


32 


611 


68 


32768 


1057 


2444 


33 


630 


70 


35937 


1123 


2520 


34 


649 


72 


39304 


1191 


2596 


35 


668 


74 


42875 


1261 


2672 


36 


687 


76 


4 6 5 5 5 


1333 


2748 


37 


706 


78 


50553 


1407 


2824 


38 


725 


80 


54872 


1483 


2900 


39 


744 


82 


5 9 319 


1561 


2976 


40 


763 


84 


64000 


1641 


3052 


41 


782 


86 


68921 


1723 


3128 


42 


801 


88 


74088 


1807 


3204 


43 


820 


9 


79507 


1893 


3280 


44 


839 


9 2 


85184 


1981 


3356 


45 


858 


94 


91125 


2071 


3432 


46 


877 


96 


97336 


2163 


3508 


47 


09 6 


98 


103823 


2257 


3584 


48 


915 


100 


110592 


2353 


3660 


49 


934 


102 


117649 


2451 


3736 


50 


953 


104 


125000 


2551 


3812 



C-fa 



APPENDIX D 

PROGRAM MODULE DESCRIPTIONS 

D. INTRODUCTION 

Included in this Appendix are short verbal descriptions of all of the 
program modules required to generate and support the GOAL data bank 
system. In this Appendix: 

Figure D-1 Indicates the functional flow during data bank 
and data bank directory initialization. 

Figure D-2 is the functional diagram of the data bank 
maintenance process. 

Figure D-3 represents the elements involved in the data bank 
initialization process. Also indicated on this diagram is 
the operation of the data bank print utility program. The 
operation and use of these two programs is completely inde- 
pendent of one another - they have been included on the same 
diagrams for convenience. 

Diagrams D-4, D-5, and D-6 depict the three phases of the data 
bank maintenance process. 

Following the above diagrams are descriptions (one module per 
page) of the programs and subroutines required to support the 
data bank. The program modules and their system names are as 
follows: 

Data Bank Print Utility 



Mainline = SUPERD 








Subroutines = 


SLEW 






Data Bank Initialization Program 






Mainline = DBI 






Subroutines = 


None 






Data Bank Maintenance Program 








Mainline = MAINT 








Subroutines = 


BEGDB 


NAMESR 


RCRETN 




BUST 


SPECFY 


VMME 




DELDB 


DBEND 


COMPAR 




DELETE 


DBSEEK 


SPACE 




MACRO 


FIND 


SVSAVE 



U-1 



Data Bank Pre- Processor 

This module is actually the GOAL canpiler; action as 
a data bank pre- processor is achieved by providing 
the proper syntax tables. Documentation covering the 
GOAL compiler module is in separate documentation. 
The syntax tables required for data bank maintenance 
usage are included in this document as Appendix I. 



u-z 



DATABANK 
CAPACITY RECORD 



DATABANK 
INITILIZATION 
CONTROL CARDS 



Type(l) 
Card 



> 




"^ 

DATABANK 
INITILIZE 
PROGRAM 



\ 



1 



u 



f 

* Writes Dummy 

Blocks 

* Writes Zeroed 

Block Headers 



X 



Directory Blocking 
Factor from Constant 
Compiled into the 
Ini ti 1 ization Program 



X 



> 



\ 



V 



x^ 



* Writes Capacity 

Record "^ 

* Writes Dummy Databank 

Name Reference 



^ 



Records 




* Forms Remaining Records 
on to Free Queue 



DATA 
i BANK 

i 



<- 



Record 
Number 

= 1 



Total Number 
of Records 
Aval 1 able 

in Databank 
Fi 1 e 



Total Number 
Records Now 
Available on 
Free Queue 



Pol nter 
(Record #) to 
First Record 
on Free Queue 



Maximum 
Number of 
Al lowed 

Databanks 



Total Number 
of Databanks 
Currently in 
Use 



Directory 

Bl ocking 

Factor 



DATABANK INITIALIZATION 



Figure U-1 
U-3 



CONTROL 
CARDS 



¦¦\ 



> 



DATABANK 
MAINT- 
ENANCE 
PROGRAM 



New Member Records 
are Added to the 
Databank File 



Old Members to be 
Deleted are Removed 
from the Databank 



4i. 




DATA 
BANK 




NEW 

DIREC- 
TORY 

ENTRIES] 



Entries to be 
Deleted are Marked 
in the Directory 



^ 




SORTED NEW 
DIRECTORY 
ENTRIES 



DIREC- 
TORY 



.-^ 




DIRECTORY 

CONSTRUCT 

PROGRAM 



If Merge Successful 
Final Operation is 
Replacement of the 
Old Directory with 
the New Di rectory 



-li^ 



^ 



MERGE OLD DIRECTORY WITH NEW BY: 

* Removing Entries Marked for 
Deletion 

* Inserting New Entries 



4. 



I 



<^ 



TEMPORARY 

NEW 
DIRECTORY 



Figure D-2. DATABANK MAINTENANCE PROCESS 



L..., 



e 



Data Bank 

Di rectory 

Work Data Set 



o 



Ini ti al izatinn 

Control 
Parameters 



//FT05F001 

.^ 



^ 



//FT13F001 



Data Bank 
Initial i zatlon 

Program 
(OBI) 



//FT06F001 



//FTllFOOl 




//FT10F001 



Data Bank 
D i r e c 1 ry 



© 




Data Bank 
File 



//FTllFOOl 



^ 



//FTlOFOOl 



A 



Data Bank Print 
Utility Program 

(SUPERD) 



v!2 



> 



Maintenance 
Listing 



L. 



) Letters in circles are 



Data Set Reference 
Numbers; see 
APPENDIX E for 
record formats 



//FT06F001 



Printer Dump 

All 
Data Banks 




DATA BANK 
IN_ITIALI2ATI0N AND 
PRINT UTILITY 
PROGRAMS 



NOTE - PROGRAMS (DBI) AND (SUPERD) MAY 

BE RUN INDEPENDENTLY OF ONE 

ANOTHER 

U-b 



Figure U-3. 




Ar 



Control 
Deck 



//FT05F001 



¦^ 



Data Bank 
Pre-Processor 
Program 



f^A2^ 



//FT06F001 



> 



Pre- 
processor 
L i s t i n ci„ 



//FT20F001 




Fixed-Format 
Control Card 
Images 



G) 



//FT09F001 



^ 



Alpha 
Character 
Reference 



Data Bank 

Mai ntenance 

Program 

(MAINT) 



New 
Unsorted 
Directory 
Entries 




//FT12F001 



7^r~7K 



//FT06F001 



//FTIlFOOl 







//FT10FD01 



¦^ 



© 



Q 



^ 



Maintenance! 
Listing I 



Data Bank 
Di rectory 



Data Bank 
File 



o 



To PHASE-2 
Mai ntenance 

Process 



Letters in circles are Data Set Reference 
Numbers; see APPENDIX E for record 
formats 

U-6 



PHASE-1 DATA BANK 

MAINTENANCE 

PROCESS 



Figure D-4 



From 

PHASE-1 

Maintenance 

Process 




^ F ) 



New 
Unsorted 
Di rectory 
Entries 



//SORTWKOl 
//S0RTWK02 
//S0RTWK03 



¦^ 




± 



//SORTIN 



¦e 



Three (3) Intermediate 
SORT Work Data Sets 



a 



Control 
Card 



//SYSIN 



^ 



Standard 

OS/360 

Sort/Merge 

Utility 

Program 

(IERRC0OO) 



//SORTLIB 




Standard 
OS/360 

Sort 
Library 



il 



//SYSOUT 



-^ 



Statistics 
Listing 



//SORTOUT 



^ 




Sorted 
Di rectory 
Entries 



O 



Letters in circles are 
Data Set Reference 
Numbers; see 
APPENDIX E for 
record formats 



To 
PHASE-3 
-^ Maintenance 
Process 



PHASE-2 DATA BANK 

MAINTENANCE 

PROCESS 



Figure U-5, 
D-7 



From 
PHASE-2 
Maintenance 
Process 




New 
Sorted 
Di rectory 
Entries 



//FT12F001 



Data Bank Directory 
Construct Maintenance 

Program 

(DCON) 



7F 



//FT13F001 



7K 



//FT06F001 



V 



a 



1 



Matntenanc 
^ Listing 



//FTllFOOl 




O 




Data Bank 
Directory 



Directory 

Work 
Data Set 



o 



Letters in circles are Data Set 
Reference Numbers; see 
APPENDIX E for record 
formats 



PHASE-3 DATA BANK 

MAINTENANCE 

PROCESS 



Figure 0-6. 
D-B 



GOAL DATA BANK ROUTINE 



NAME - SUPERD 



TYPE - FORTRAN Mainline 



FUNCTION - Provides printer dump of the current data bank 

contents 

CALLED BY - Not Applicable 



SUBROUTINES 

CALLED - SLEW 



DESCRIPTION - This module prints the contents of all active 

data banks. Using the directory, all members of 
each data bank are listed in alphabetic order by 
member (record) name. 



D-9 



GOAL DATA BANK ROUTINE 



NAME - SLEW 



TYPE - FORTRAN Subroutine 



FUNCTION - Provides paging and title strips for SUPER data bank 

print utility program 

CALLED BY - SUPERD 



SUBROUTINES 

CALLED - None 



DESCRIPTION - Provides paging and title strip printing for the 

SUPERD print utility program. 



u-10 



GOAL DATA BANK ROUTINE 



NAME - DBI 



TYPE - FORTRAN Mainline 



FUNCTION - Data bank file and data bank directory ini ti 1 i zati on 

(record pre-formatting ) 

CALLED BY - Not Applicable 



SUBROUTINES 

CALLED - None 



DESCRIPTION - Under control-card control, this module pre-formats 

the records of the data bank file and the data bank 

directory by: 

composing and writing the data bank capacity 
record ; 

initializing and writing all data bank reference 
records; these records also require chaining 
together; 

filling the remainder of the data bank with 
a chain of dummy records; 

writing dummy blocks into the data bank 
directory and directory utility data set. 



u-11 



GOAL DATA BANK ROUTINE 

NAME - MAINT 

TYPE - FORTRAN Mainline Program 

FUNCTION - Mainline root program for all phase 1 maintenance 

actions; reads control card input and invokes the 
proper subroutine for further processing 

CALLED BY - Not Applicable 



SUBROUTINES 

CALLED - DELDB, DBEND, SPECFY, SVSAVE, MACRO, DELETE, 

BEGDB, NAMESR, BUST 



DESCRIPTION - This module serves to process input cards, determine 

their nature, and invoke the proper subroutine for 
completion of the processing. Each subroutine, after 
accomplishing its required action, returns control to 
MAINT for further processing of the input stream. 



U-12 



GOAL DATA BANK ROUTINE 

NAME - BEGDB 

TYPE - FORTRAN Subfoutine 

FUNCTION - Process a BEGIN DATABANK control card; open a 

Data Bank for maintenance 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - VNAME, DBSEEK, BUST 



DESCRIPTION - This subroutine is utilized to process a BEGIN 

DATABANK control card. The named Data Bank is sought 
within the current Data Bank data set. If it already 
exists, the Data Bank open flag (DBN) is set with the 
Data Bank reference number. If the Data Bank is new, 
the DBN flag is set in the same manner; the new Data 
Bank Reference Record is composed and written into the 
Data Bank before return to the caller. 



Lj-13 



GOAL DATA BANK ROUTINE 

NAME - BUST 

TYPE - FORTRAN Subroutine 

FUNCTION - Output to the printer a standard error number 

diagnostic message. 

CALLED BY - MAINT, BEGDB, DELDB, DELETE. MACRO, NAMESR, SPECFY, 

DBEND, DBSEEK, FIND, VNAME, SPACE 



SUBROUTINES 

CALLED - RCRETN 



DESCRIPTION - An error message number provided as a parameter by the 

caller module is printed in a standard error message 
format. A non-zero Return Code is established in the 
OS/360 via a call to RCRETN from this subroutine. 



U-14 



GOAL DATA BANK ROUTINE 



NAME - DELDB 



TYPE - FORTRAN Subroutine 



FUNCTION - Process a DELETE DATABANK control card 



CALLED BY - MAINT 



SUBROUTINES 

CALLED - VNAME, DBSEEK, BUST 



DESCRIPTION - The reference number of the required Data Bank is 

located via the DBSEEK subroutine. Using this number 
and the Data Bank Directory, all members of the named 
Data Bank are returned to the record Free Queue in the 
Data Bank data set. The existing Directory references 
to the deleted members are marked for deletion. 



U-15 



GOAL DATA BANK ROUTINE 

NAME - DELETE 

TYPE - FORTRAN Subroutine 

FUNCTION - Deletes a named member from the current open 

Data Bank; processes a DELETE control card 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - VNAME, FIND, BUST 



DESCRIPTION - The Data Bank Directory is used to locate the 

control card named member in the Data Bank currently 
opened. Once the required record is located, it is 
returned to the Data Bank Free Queue. The applicable 
Directory entry is marked for deletion. 



U-lb 



GOAL DATA BANK ROUTINE 

NAME - MACRO 

TYPE - FORTRAN Subroutine 

FUNCTION - Processes MACRO control cards; enters the new 

MACRO into the Data Bank currently open 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - VNAME, SPACE, BUST 



DESCRIPTION - Processing of all MACRO input cards is accomplished 

in this subroutine. Space is retrieved within the 

currently open Data Bank, and the new MACRO records 
composed and inserted. 



0-17 



GOAL DATA BANK ROUTINE 
NAME - NAMESR 

TYPE - FORTRAN Subroutine 

FUNCTION - Provides processing for Subroutine Name Records 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - VNAME, SPACE. BUST 



DESCRIPTION - Subroutine name control cards are parsed and processed 

via this subroutine. Subroutine name record construction 
is accomplished and the new record written into the 
currently open Data Bank. 



U-18 



GOAL DATA BANIC ROUTINE 

NAME - SPECFY 

TYPE - FORTRAN Subroutine 

FUNCTION - Used to process SPECIFY control cards j creates new 

Function Designator Records 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - SPACE, BUST 



DESCRIPTION - New Function Designator records are created by this 

subroutine. All parsing of the SPECIFY card contents 
is accomplished within this subroutine. 



U-19 



GOAL DATA BANK ROUTINE 

NAME - DBEND 

TYPE - FORTRAN Subroutine 

FUNCTION - Closes an open Data Bank; this subroutine processes 

an END DATABANK control card 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - BUST 



DESCRIPTION - This subroutine is invoked to process an END DATABANK 

control card. The data bank open flag (DON) is set 
to the zero (off) state. Only DELETE DATABANK control 
cards will be recognized by the MAINT mainline until 
another Data Bank is opened (via a BEGIN DATABANK 
control card). 



U-20 



GOAL DATA BANK ROUTINE 



NAME - DBSEEK 



TYPE - FORTRAN Subroutine 



FUNCTION - Determines if a named Data Bank already exists 



CALLED BY - BEGDB, DELDB 



SUBROUTINES 

CALLED - BUST 



DESCRIPTION - Using a Data Bank name (name plus revision label, if 

appropriate), this subroutine returns one of three 
pieces of information to the caller: 

(1) If the Data Bank already exists, the caller is 
informed of the Data Bank reference number; 

(2) If the Data Bank does not yet exist, the caller 
is informed of a Data Bank reference record 
number that is available for establishing a new 
Data Bank; 

(3) If the Data Bank does not exist and all usable 
Data Bank reference records have been utilized, 
an appropriate error indication is given. 



U-21 



GOAL DATA BANK. ROUTINE 



NAME - FIND 



TYPE - FORTRAN Subroutine 



FUNCTION - Locate a specific member of a given Data Bank 



CALLED BY - DELETE 



SUBROUTINES 

CALLED - COMPAR, BUST 



DESCRIPTION - Using the Data Bank Directory, this subroutine locates 

a required member. The name of the member is supplied 
as a calling parameter; the required Data Bank reference 
number is provided as the first four bytes of the name. 
Upon finding the required member, the sought record is 
brought into memory and the caller informed of its 
relative record number within the Data Bank data set. 



U-22 



GOAL DATA BANK. ROUTINE 

NAME - RCRETN 

TYPE - Assembler Language Subroutine 

FUNCTION - The function of this subroutine is to establish the 

OS/360 Return Code upon termination of the MAINT phase 
1 maintenance module. Execution (go/nogo) of the 
programs in subsequent job steps is controlled via this 
Return Code. 

CALLED BY - BUST 



SUBROUTINES 

CALLED - None 



DESCRIPTION - Non-error execution of the MAINT module results in a 

zero Return Code indication upon MAINT termination. 
Subsequent phases of the maintenance process can use 
this code as an indication that normal execution can 
continue. Should an error occur during MAINT execution 
that would render execution of the subsequent maintenance 
steps inappropriate, a non-zero Return Code is 
established by call to the RCRETN subroutine from the 
error diagnostic subroutine BUST. 



u-23 



GOAL DATA BANK ROUTINE 



NAME - VNAME 



TYPE - FORTRAN Subroutine 



FUNCTION - Validates and isolates a name bounded by parenthesis 
CALLED BY - BEGDB, DELDB, DELETE, MACRO, NAMESR 



SUBROUTINES 

CALLED - BUST 



DESCRIPTION - This subroutine scans an indicated portion of an input 

card and attempts to isolate a standard name bounded by 
parenthesis. The name can be 1 - 32 characters in 
length. The first character must be a letter; subsequent 
characters can be letters and/or digits. An appropriate 
error message is issued if an error is detected in 
either the name contents or in the delimeters. 



U-2A 



GOAL DATA BANK. ROUTINE 

NAME - COMPAR 

TYPE - Assembler Language Subroutine 

FUNCTION - Perform a logical {non-arithmetic) compare of 

two EBCDIC names 

CALLED BY - FIND 



SUBROUTINES 

CALLED - None 



DESCRIPTION - This subroutine is used as a FORTRAN function 

subprogram. It is designed to be used in an 

arithmetic FORTRAN statement; the value returned to 

the caller is either (-1), (0), or (+1). Two named 

parameters are compared logically with the following 

impl i cations: 

Parameter 

Rel ation Return 

A < B -1 

A = B 

A > B +1 



D-25 



GOAL DATA BANK ROUTINE 

NAME - SPACE 

TYPE - FORTRAN Subroutine 

FUNCTION - Finds a place to write a new record Into the 

Data Bank data set 

CALLED BY - MACRO, NAMESR, SPECFY 



SUBROUTINES 

CALLED - BUST 



DESCRIPTION - This subroutine locates the next available singular 

record space in the Data Bank. The Data Bank Free Queue 
total and pointer fields are updated and the Data Bank 
Capacity Record re-written with the adjusted totals. 
The record selected for availability has been read 
into memory and is ready for use when return to the 
caller is effected. 



0-26 



QOAL DATA. BANIC ROUTINE 

NAME - SVSAVE (Alternate entry point to RCRETN subroutine) 

TYPE - Assembler Language 

FUNCTION - The memory address of the OS/360 Supervisor is 

established via this entry to the RCRETN subroutine. 
This address is required for subsequent correct operation 
of the RCRETN subroutine. 

CALLED BY - MAINT 



SUBROUTINES 

CALLED - None 



DESCRIPTION - The address of the OS/360 Supervisor is required for 

operation of the RCRETN subroutine; this address is 
used as a RCRETN return point. The address is establishel 
as a part of the initil ization sequence of the MAINT 
mainline program. 



u-27 



APPENDIX E 
DATA RECORD FORMATS 



E.l INTRODUCTION 



This Appendix contains record descriptions for all of the data sets re- 
quired for data bank and data bank directory initialization, maintenance, 
and usage. Each of the data sets is referred to by a "file reference 
letter". The reference letters are those used in the functional flow 
illustrations of Appendix E. They are itemized in the table following: 



Data Set Description 

Pre-processor program control card input 

Pre-processor program listing 

Fixed- format control card images 

Maintenance program alphanumeric character 
set reference 



File 

Reference 

Letter 


See 
Figure 


Al 


D-4 


A2 


D-4 


A 


D-4 


B 


D-4 


C 


D-4 


D 


D-3 



D-4 
D-6 



Phase-1 maintenance program listing 
Data bank directory 



E D-3 Data bank file 
D-4 
D-6 

F D-4 New unsorted directory entries 
D-5 

G D-5 Standard OS/360 Sort/Merge utility program 

library (SySl.SORTLIB) 

H D-5 Sort/merge utility program listing 

I D-5 Sort/merge utility program intermediate work 

data sets 

J D-5 Sort/merge utility program control card 



E-1 



File 

Reference 

Letter 


See 
Figure 


K 


D-5 
D-6 


L 


D-6 


M 


D-6 


N 


D-3 





D-3 


P 


D-3 



Data Set Description 
Sorted new directory entries 

Directory work data set 

Directory construction program listing 

Initialization program control card input 

Initialization program listing 

Printer dump of data bank 

Figures E-1 through E-4 inclusive, form a sequential sample of the printer 
listings that might occur as the result of a data bank maintenance operation. 



E-2 



;OAL COMPILER SOURCE RECORD LISTING 



OJ 



RECORD 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

II 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 



SOURCE RECORD 

BEGIN DATABANK (SAHPLED8) REVISION A 
SPECIFY <PRIMARY SSCU ON SWITCH> AS L 
SPECIFY <VENT MOTOR F1ELD> AS LOAD TY 
SPECIFY <CDC SET CKT> AS LOAD TYPE CL 
SPECIFY <MANIFOLD PRESSURE LOW LAMP> 
SPECIFY <IU COOLANT PRESS> AS SENSOR 
SPECIFY <EST> AS SENSOR TYPE CLOCK AD 
SPECIFY <LINE PRINTeR> ALSO AS <360/P 
SPECIFY <CRr2> AS SYSTEM TYPE CRT ADD 
SPECIFY <LOG> AS SYSTEM TYPE TAPE ; 
SPECIFY <P«INTER BUSY> AS SYSTEM TYPE 
SPECIFY <PROCEDURE IN PROGRESS FLAG> 
SPECIFY <GOAL SR NAME> AS SUBROUTINE 
NAME (POWER ON » SUBROUTINE IFDRT4) ; 
NAME (ABCDEFG) PROGRAM IFQRT25) ; 
BEGIN MACRO ABC t A > , ( B I , t C ) t<A> ; 

(ABC) = (A) 

<DEF) = (8» 

IGHIJ = (C) 

tJKL) = <A> 
END MACRO ; 
END DATABANK ; 
FINIS 



OAO TYPE DISCRETE ADDRESS 252 ; 

PE ANALOG ADDRESS 0063 ; 

OCK ADDRESS 0040 ; 

AS SENSOR TYPE DISCRETE ADDRESS 4123 

TYPE ANALOG ADDRESS 0049 ; 

DRESS 6 ; 

RINTER> AS SYSTEM TYPE PRINTER ; 

RESS I ; 



INTERRUPT ; 
AS SYSTEM TYPE 
(F0RT23) ; 



FLAG I 



Figure E-1 . 



SAMPLE DATA BANK 
PRE-PRQCESSOR 
LISTING 



Refer to File Reference Letter A2 



GOAL COMPILER DIAGNOSTIC SUMMARY 



TOTAL NUMBER OF SOURCE RECORDS: 
TOTAL NUMBER OF STATEMENTS: 19 
TOTAL NUMBER OF WARNINGS: 
TOTAL NUMBER OF ERRORS : 
HIGHEST CONDITION CODE WAS 



23 



I 



DATABANK (SAMPLEDB) 
SPECIFY <PRIMARyGSCUONSWITCH> 
SPECIFY <VENTMOTORFieLO> 
SPECIFY <CDCSETCKT> 
SPECIFY <HAMIFOLDPRESSURELOWLAMP> 
SPECIFY <IJCOOLANTPRESS> 
SPECIFY <EST> 
SPECIFY <LINEPRINTER> 
<360/PRINTER> 
SPECIFY <CRT2> 
SPECIFY <LOG> 
SPECIFY <PRIMTERBUSY> 
SPECIFY <PROCEDUREINPROGRESSFLAG> 
SPECIFY <GDALSRNAME> 
NAME tPOWERON) 
NAME (ABCOEFG) 
MACRO (ABC) 
I A ) 
(B) 
(C) 
<A> 

(ABC) = (A) 

(DEF) = (B) 

(GHIJ = (C> 

<JKL> = <A> 
END MACRO 
END DATABANK 



(A) 






LOAD 


DISCRETE 


0252 


LOAD 


ANALOG 


0063 


LOAD 


CLOCK 


00^0 


SENSOR 


DISCRETE 


^123 


SENSOR 


ANALOG 


00'^9 


SENSOR 


CLOCK 


0006 


SYSTEM 


PRINTER 




SYSTEM 


CRT 


0001 


SYSTEM 


TAPE 




SYSTEM 


INTERRUPT 


0000 


SYSTEM 


FLAG 


0001 


SUBROUTINE 


tF0RT23) 




SUBROUTINE 


(F0RT4) 




SUBROUTINE 


(F0RT25) 





Figure E-2 



SAMPL E PHASE 
FTIETT 



1 MAINTENANCE PROGRAM 

FORMAT CONTROL-CARD IMAGES 



Refer to File Reference Letter A 



?*? TOTAL DIRECTORY ENTRIES GENERATED = 15 **? 
**? TOTAL DIRECTORY ENTRIES DELETED = *** 



I 



IEft036I - B = 90 

IER037I - G = 700 

IER038I - NMAX = 17460 

IER045I - END SORT PH 

IER049I - SKIP MERGE PH 

IER054I - RCD IH 17, OUT 

IER052I - EOJ 



17 



Figure E-3. 

SAMPLE SORT/MERGE PRINTER OUTPUT 

Refer to File Reference Letter H 



[iEtt_i3ia£aiQa3t_iIAIiSIiti 

20: DBF 

14: rtMAX 

239: DRTOT 

224: QLDTOT 

0: DELTQT 

15: SORTOT 



Figure E-4. 

SAMPLE PHASE-3 MAINTENANCE PROGRAM LISTING 

Refer to File Reference Letter M 



0: ZERO BALANCE 



I 



DATABANK MAHE: 

revision: 

REFERENCE •: 


SAMPLEDS 
A 
U 








MENdER 
(IUtiaE& 


RECORD 

eiutiBEa 


RECORD 
I3tE£ 


—QEitglEIiaM— 


&flQ&£S&. 


t]£(iaEa_tl&ll£. 


225 


509 


MACRO 


< 4 PARAMETERS) 




ABC 


225 


510 


MACRO 


SKELETON 


(ABCI 


« tl i 


225 


511 


MACRO 


SKELETON 


lOEFI 


* G2 : 


225 


512 


MACRO 


SKELETON 


(GHH 


m t3 i 


225 


513 


MACMO 


SKELETON 


(JKLI 


> e4 : 


22b 


508 


SUBROUTINE 




F0RT25 


ABCDEFG 


227 


*97 


<FD> 


LOAD CLOCK 


40 


CDCSETCKT 


228 


502 


<F0> 


SYSTEM CRT 


1 


CRT2 


229 


500 


<FD> 


SENSOR CLOCK 


6 


ESI 


230 


506 


<FD> 


SUBROUTINE 


FORT23 


GOALSRNAME 


231 


499 


<FD> 


SENSOR ANALOG 


49 


lUCOOLANTPRESS 


232 


501 


<FD> 


SYSTEM PRINTER 




LINEPRINTER 


233 


503 


<FD> 


SYSTEM TAPE 




LOG 


234 


496 


<FD> 


SENSOR DISCRETE 


4123 


MANIFOLOPRESSURELOWLAMP 


235 


507 


SUBROUTINE 




FaRT4 


POWERON 


236 


495 


<F0> 


LOAD DISCRETE 


252 


PRINARVGSCUONSWITCH 


237 


504 


<F0> 


SYSTEM INTERRUPT 





PRINTEHBUSy 


23S 


505 


<FD> 


SYSTEM FLAG 


1 


PROCEDURE I NPROGRESSFLAG 


239 


496 


<FD> 


LOAD ANALOG 


63 


VENTHOrORFIELO 



.E&lHI-EXEiliSlQB 



CDCSETCKT 

CRT2 

EST 

GOALSRNAME 

lUCOOLANTPRESS 

360/PRINTER 

LOG 

MANIFOLOPRESSURELOWLAMP 

PRIMARYGSCUONSMITCH 

PRINTERBUSY 

PROCEDURE I NPROGRESSFLAG 

VENTHOTQRFIELD 



^ 



Figure E-5 



SAMPLE DATA BANK PRINTER DUMP LISTING 
Refer to File Reference Letter P 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Control Card Input 
Al, A2, A 
Not Applicable 
Not Applicable 



These three data sets form the control input for the data bank maintenance 
process. They are discussed separately below; 

(Al) Pre-Processor Program Control Card Input 

These control cards direct the maintenance process. They are totally 
free-form in conformity with the syntax diagrams presented in this 
document as Appendix I. A sample listing of control card variations 
is to be found in Figure E-1. 

(A2) Pre-Processor Program Listing 

The pre-processor program is actually the GOAL compiler module directed 
by a suitable syntax table. The listing that is output is an 80-80 list- 
ing of the control cards input, plus any errors that may have been 
detected in the control -card input. The pre-processor error messages 
are to be found in this document in Appendix H. Figure E-1 provides an 
example of the listing. 

(A) Phase-1 Maintenance Program Control -Card Input 

This data set forms the input control for the Phase-1 data bank main- 
tenance program (MAINT). The card images may be punched and entered 
directly to MAINT, or, the images may be artificially generated as a 
normal output from the data bank pre-processor program. 

The control image consists of a total of six (6) distinct fields in 
fixed positions. Not all fields are required for any control card type. 
Figure E-6 describes the bounds of the six fields. 

A sample of the variations of control images possible is illustrated in 
Figure E-7. Usage of the various types is discussed in the following 
paragraphs: 

A data bank is opened for maintenance by the appearance of a 
DATABANK control card; the same data bank is closed by an END 
DATABANK card. 

All control variations, with the single exception of a delete 
data bank (DELETEDB) option, are legal only between a DATABANK 
and an END DATABANK pair. The DELETEDB option is legal only 
when a data bank has been closed. 



E-7 



All function-designator types except for PRINTER, CRT, TAPE, 
and SUBROUTINE require an address field (see "Fb" field, Figure 
E-6). This address field is a mandatory four-digit field - lead- 
ing zero(s) to be supplied as applicable. 

For the examples of function designators indicated in Figure E-7, 
the print expansion field and the function designator name fields 
are identical. If the print expansion field is to be unique, two 
control images will be required. See page 2 of Figure E-7. 

The total number of formal parameters allowed on a macro will be 
ten {10). Each parameter may be a GOAL name or function designator. 



E-8 





1 


2 

H 


3 


t 


5 


& 


1 


3 


9 


(0 


tl 


12 


' 


m 


15 


IG 


n 


IS 


19 


20 


21 


22 


23 


2. 


2J 


26 


21 


28 


29 


30 


31 


32 


33 


at 


35 


36 


37 


38 


39 


.. 


;^ 


m 


M3 


MM 


M5 


MG 


M7 


MB 


\^ 


50 


51 


52 


53 


5^5i 


5. 


57 


58 


59 


eo 


El 


62 


E3 


5M 65 


66 


67 


6B 


69 


70 


71 


72 


73 


7M 


75 


76 


77 


7» 


79 


to 








































































































- 
















































r 


^ 




F 


i 










































F 


z 












































F3 
















"? 




















F? 
















L 












































































1 


































- 




















































•^ 






























^ 


















* 
































. 








- 































































- 


















































































































































^ 


















































































































































¦¦( 










¦i 






- 
























































































































F<i 










































































..... 








... 




¦ 




























' — 1 








































































j 








































































































































n 
































































































































































































































^4 [ [ ¦ 






















































































^ t 1 




































































































n ' ¦ 


















„.. 















































m 

! 

y3 



Figure E-6. FIXED FIELD LAYOUT - DATA SET REFERENCE LETTER "A' 



DATABANK (ILLUSTRATIONS) 

SPECIFY <PRIMARY GSCU ON SWITCH> 

SPECIFY <VENT MOTOR FIELD> 

SPECIFY <CDC SET CKT> 

SPECIFY <MANIFOLD PRESSURE LOW LAMP> 

SPECIFY <IU COOLANT PRESS> 

SPECIFY <EST> 

SPECIFY <LINEPRINTER> 

SPECIFY <CRT2> 

^ SPECIFY <LOG> 

SPECIFY <EVENT12> 

SPECIFY <REMEMBER 

SPECIFY <GOAL SR NAME> 

MACRO (SAMPLEMACRONAME) 

(PARMl ) 

READ <GMT> AND SAVE AS (PARMl) ; 

END MACRO 

END DATABANK 

Figure E-7 SAMPLE FIXED-FORMAT CONTROL-CARD IMAGES 
(Page 1 of 2) (DATA SET REFERENCE NUMBER "A"! 



LOAD 


DISCRETE 


0252 


LOAD 


ANALOG 


0063 


LOAD 


CLOCK 


0040 


SENSOR 


DISCRETE 


4123 


SENSOR 


ANALOG 


0049 


SENSOR 


CLOCK 


0006 


SYSTEM 


PRINTER 




SYSTEM 


CRT 


0013 


SYSTEM 


TAPE 




SYSTEM 


INTERRUPT 


0000 


SYSTEM 


FLAG 


0614 


SUBROUTINE 


(FORT23) 





DELETE (OLDNAME) 

DELETE <OLD FUNCTION DESIGNATOR> (More control-card samples) 

DELETEOB (OLDDATABANK) (REV IS I ONXXX ) 

Note: The print expansion field and the function designator name are identical on 
all of the samples presented on page 1 of this figure. 

The following example is presented to illustrate the format required to enter 
a function designator with unique name and print-expansion formats - 2 cards 

SPECIFY <NORMAL FD NAME> (Note - remainder of first card left blank) 

<FD PRINT EXPANSION NAME - 2ND CARD> SENSOR ANALOG 0049 



Figure E-7. (Page 2 of 2) SAMPLE FIXED-FORMAT CONTROL-CARD IMAGES 

Refer to File Reference Letter A 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Alphabetic Character Reference 

B 

CHRTAB 

Not Applicable 



This dataset forms the character reference to be used in scanning 
control-card records. The dataset consists of a single card image 
to be punched as follows: 



Card 




Card 




Card 




Column 


Character 


Col umn 


Character 


Col umn 


Character 


1 


1 


21 


K 


41 


< 


2 


2 


22 


L 


42 


( 


3 


3 


23 


M 


43 


) 


4 


4 


24 


N 


44 


' (ap 


5 


5 


25 





45 


+ 


6 


6 


26 


P 


46 


- 


7 


7 


27 


Q 


47 


* 


8 


8 


28 


R 


48 


1 


9 


9 


29 


S 


49 


1 


10 


(zero) 


30 


T 


50 


# 


n 


A 


31 


U 


51 


$ 


12 


B 


32 


V 


52 


-^ 


13 


C 


33 


w 


53 


& 


14 


D 


34 


X 


54 




15 


E 


35 


Y 


55 


s 


16 


F 


36 


z 


56 


* 


17 


G 


37 


= 


57 


blank 


18 


H 


38 


: 


58-80 


blank 


19 


I 


39 


> 






20 


J. 


40 


> 







E-12 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Databank Maintenance Module Listing 

C 

Not Applicable 

Not Applicable 



The output from this module is basically a single-spaced printer listing 
of the input card deck (File Reference Letter = A). 

If the step terminates due to error, the following message will appear on 
the same line as the last input card processed: 



***** 



ERROR # NNN OCCURRED ***** 



For a description of the error message numbers ("NNN" 1n the above message), 
see the standard error message listing section of this document. 

If the step proceeds normally to conclusion (no errors), the following totals 
are printed after the last control card: 

*** TOTAL DIRECTORY ENTRIES GENERATED = NNNNNN *** 
*** TOTAL DIRECTORY ENTRIES DELETED = NNNNNN *** 
For an example of this listing, see Figure E-2. 



E-13 



Symbol ic- 
Bytes- 



i^— Directory Header Block 






HRN 



HTA 



I 
-* — 



HTU 
4 



Di rectory 
Block # 



Total # 
Entries 
Possi ble 
(N) 



Total # 
Entries 
Used 



^' 



1^ 



A Directory Block 
(N Directory 
Entries) 



_^ 



A 



r 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Directory Block 

D, L 

DBLOCK (383) 
DIR (19) 

Not Applicable 



/ 



^ 



Symbol i c — ^ 
Bytes — > 



A Directory Entry 



-> 



ENT(1 .N) 



ENT(2,N) I SK(1,.N)_ 
4 i 2 



SK(2.N) JSK(3-34,N) 
2 i 64 (32-char) 



Record 
Poi nter 



Delete 
Field 
0=acti ve 

1=DELETE 



Databank # 



Search Key 



< 



m 
I 



Recoj"d Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Fomat Number 



FW 
Subscript 

1 

2 

3 

4 

5 

6 

7 

8-43 



HW 
Subscript 

1 

3 

5 

7 

9 

11 

13 

15-86 



Field 

Length 

(Bytes) 

4 
4 
4 
4 

4 

4 

4 

144 



Databank Capacity Record 

E 

CAPCTY (43) 

Rl 



Type: 

A=Alpha 

N=Numer1c 

N 
N 
N 
N 
N 
N 
N 



Symbolic 

Name Field Description 

Rl Record number; always = 1 for Capacity Record 

RAVAIL Total # record allocated for databank 

FQTOT Total # records on FREE-QUEUE 

FQPTR Pointer to first record that is on the FREE-Q 

DBMAX Total # databanks allowed 

DBCUR Total # databanks currently in use 

DBF Directory blocking factor 



NOT USED IN THIS RECORD FORMAT 



m 
I 



Oi 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



FW 
Subscript 

1 

2 



4 
5 
6 

7 

23 



HW 
Subscrip t 

1 
3 



7 

9 

11 

13 

45 



Field 

Length 

(Bytes) 

4 
4 



4 
4 
4 

64 

64 



Databank Name Reference Record 

E 

DBREC (43) 

R2 



Type: 

A=Alpha 

N=Nunieric 

N 

N 



Symbolic 
Name 

DBRN 
PNEXT 

RTYPE 



N 


RECTOT 


N 


PLAST 


N 


SDB 


A 


SER 


A 


EPR 



Field Description 
Record Number 

Pointer to next Databank Reference Record; if this 
is the last record in the chain, PNEXT = 

= 1 (one) means record currently not in use 
= 2 (two) means record in use 

Set to equal the total number of allowed databanks 

Pointer to last Databank Reference Record 

Databank reference number; set to equal the current 
record number (DbRN) 

32-character databank search key (member name); in 
FORTRAN 32A1 (halfword) format 

32-character databank name REVISION title; if none 
specified, field is blank; in 32A1 FORTRAN halfword 
format 



39-43 



77-86 



40 



NOT USED WITH THIS RECORD FORMAT 



m 
I 



Recofd Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Foimat Number 



FW 

Subscr 


ipt 


HW 
Subscn 


pt 


Field 

Length 

(Bytes) 


1 




1 




4 


2 




3 




4 


3 




5 




4 


4 




7 




4 


5 




9 




4 


6 




n 




4 


7 




13 




64 


23 




45 




64 


39 




77 




2 



Function Designator Record 

E 

DBREC (43) 

R3 



Type: 

A^Alpha 

H=Numer1c 

N 

N 
N 
N 
N 



N 
A 
A 

N 



Symbolic 
Name_ 

DBRN 

PNEXT 

RTYPE 

RECTOT 

PLAST 

SDB 

SER 

ERR 

GPDATA (1) 



Field Description 
Record number 

Always zero with this record type 

Record type = 3 indicates a Function Designator 

Always = 1 for this record type 

Pointer to last record in this sequence; for this 
record type, always set to point to this record, 
i.e., PLAST = DBRN 

Databank reference number of the databank of which 
this Function Designator is a member 

32-character Function Designator search key; in 
FORTRAN (32A1) halfword format 

32-character Function Designator print expansion 
name in FORTRAN (32A1 ) halfword format 



Function Designator type: 

1 = Load Discrete 

2 = Load Analog 

3 = Load Clock 

4 = Sensor Discrete 

5 = Sensor Analog 

6 = Sensor Clock 



7 = System Printer 

8 = System CRT 

9 = System Tape 

10 = Issue Subroutine 
n = System Interrupt 
12 = System Flag 



CO 



Recofd Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Function Designator Record (Continued) 

E 

DBREC (43) 

R3 



Field Type: 

FW HW Length A=Alpha Symbolic 

Subscript Subscript (Bytes) N=Numeric Name Field Description 

* * For Function Designator Types 1 through 9, inclusive, and 11, 12 * * 

N/A 78 2 N GPDATA (2) Function Designator hardware address 

40-43 79-86 16 NOT USED WITH THIS RECORD VARIATION 

* * For Function Designator Types 10 * * 

M/A 78 2 N GPDATA (2) Subroutine FORTRAN name lengtn (1 to b, max) 

40-42 79-84 2-12 A GPDATA (3) Subroutine FORTRAN name; one to six halfwords 

through (8) 

43 85 4 NOT USED WITH THIS RECORD VARIATION 



Recoird 


Name 






• MACRO 


Header Record 


File Reference 


Letter 




; E 




FORTRA^ 


t Symbol 


ic Base 


Declaration 


: DbREC 


(43) 


Record 


Format 


Number 




; R4 




FW 
Subscri 


HW 
pt Subscript 

1 


Field 
Length . 
(Bytes) 

4 


Type: 

A=Alpha 
N=Nuiiieri c 

N 


Symbolic 

Name 


1 


UbRN 


2 




3 


4 


N 


PNEXT 


3 




5 


4 


N 


RTYPE 


m 4 




7 


4 


N 


RECTOT 


lO 












b 




9 


4 


N 


PLAST 


6 




11 


4 


N 


SDB 


7 




13 


64 


A 


SER 


23 




45 


64 


A 


£PR 



39 



77 



Field Description 

Record Number 

Always non-zero with this record type; points to 
first I'^CRO Skeleton record (type = b) of the MACRO 

Record type - 4 means MACRO Header Record 

Total # records for this MACRO; sum of all MACRO 
Skeleton (type = 5) + 1 for MACRO Header record 

Points to last MACRO Skeleton (type =5) record 
belonging to this MACRO 

Databank reference number of the databank to which 
this MACRO belongs 

32-character MACRO name in FORTRAN (32A1) fomat 

32-character blank (field unused in this record type) 
field in (32A1) FORTRAN format (nalfwords) 

GPDATA(l) Total # of format parameters aeclarea witn this 
MACRO, NOTE - it is possible for a MACRO to have 
no (zero) formal parameters 



N/A 



78-85 



18 



NOT USED WITH THIS RECORD TYPE 



Recopd Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



o 



FW 
Subscript 

1 
2 

3 
4-43 



HW 
Subscript 

1 

3 

5 
7 



Field 

Length 

(Bytes) 

4 

4 

4 
160 



MACRO Skeleton Record 

E 

DBREC (43) 

R5 



Type: 

A=Alpha 

N=Numeric 

N 

N 



N 
A 



Symbol i c 
Name 

DBRN 

PNEXT 

RTYPE 
IMAGE 



Field Uescription 
Record Number 

If not last skeleton record for this i^CRO, points 
to next skeleton image; if last, PNEXT = 

Record type = 5 

Scanned and processed MACRO skeleton caro-iniage 
in FORTRAN (80A1) format 



I 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Fomat Number 



Subroutine Name Record 

E 

DBREC (43) 

Rb 



Field Type: 

FW HW Length A=Alpha Symbolic 

i"^s<^'^^P^ ^"bsc'^TPt (Bytes) N=Nunieric Name Field Description 

1 1 4 N UBRN Record Number 

2 3 4 N PNEXT Zero 

3 5 4 N RTYPE Record type = 6 

4 7 4 N RECTOT Always = 1 for this record type 

5 9 4 N PLAST Points to this record number (DBRN) 

6 n 4 N SDB Databank reference number of the databank to which 

this subroutine belongs 

7 13 64 A SER 32-character subroutine GOAL name in FORTRAN {32A1 ) 

half word format 

EPR Unusea in this record type 

i3puATA(l) Unused in this recora format 

GPDATA(2) Number of characters in subroutine FORTRAN namei 
range is 1 to b 

GPDATA(3) Subroutine FORTRAN name; one to six nalfworas witn 
thru (S) characters in FORTRAN (Al) format 

NOT USED IN THIS RECORD FORMAT 



23 


45 


64 


A 


39 


77 


2 


N 


N/A 


78 


2 


N 


40-42 


79-84 


2-12 


A 


43 


85 


4 


N 



Record Name 

File Reference Number 

FORTRAN Symbolic Base Declaration 

Record Format Number 



New Directory Entry 

F, K 

SORT (20) 

Not Applicable 



I 

[SI 
l\3 



Symbol ic 
Bytes 



<r 



->[ STY PE 
->* 4 



Sort 

Record 

Type 



One New Directory Entry- 



DRPTR 



DELF 



DDBN 



SERCH (32) 



64 (32-char) 



-> 



Record ; Delete Databank Search Key 
Pointer Field Reference (in (32A1 ) | 

' = Number FORTRAN halfword' 

(active) format 

1 = Process Record (DRPTR = total # new directory entries) 

2 = Normal Directory Entry 

3 = EOF (End-of-Fi le) Dummy Record 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Standard Sort/Merge Library 

G 

Not Applicable 

Not Applicable 



This dataset is the standard Sort/Merge Utility Program library required 
for operation un-er 05/360. This dataset is generated as a portion of 
the Operating System and is customarily cataloged under the data set name 
"SYSl.SORTLIB". 



E-23 



Record Name : Sort/Merge Utility Printer Output 



File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



H 

Not Applicable 

Not Applicable 



Indicated below is a sample of the output as produced by a successful run of 
this utility program. Space allocation for the three intermediate work 
datasets (File Reference Letter = I) was 100 tracks for tfiis run. 

IER036I - B = 90 

IER037I - G = 625 

IER038I - NMAX = 

IER045I - END SORT PH 

IER049I - SKIP MERGE PH 

IER054I - ROD IN 30,0UT 30 

IER052I - EOJ 

The exact meaning of the above numbered messages is contained In the following 
OS/360 Reference Manual : 

IBM System/360 Operating System 

Sort/Merge 

Form # GC28-6543-6 

The only real significance that this message sequence has to the GOAL compiler 
is that no error messages are present. 



E-24 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Sort/Merge Intermediate Storage 

I 

Not Applicable 

Not Applicable 



These three datasets form the intermediate workspace reguired for the Sort/ 
Merge Utility program operation. The total disk space (1n tracks) for a 
2314 Disk sort is given by the following formula: 



SPACE = 3 (# of directory entries to be sorted -_max) 



+ 6 



This computed space is to be divided evenly between the three datasets. The 
formula above is a condensation of the standard Sort/Merge computation covered 
in Section 2, pp 43 of the following 03/360 reference manual: 

IBM System/ 360 Operating System 

Sort/Merge 

Form # GC28-6543-6 

Figure E-8 of this document tabul arizes the storage requirements for the sort 
work data sets for directory blocking factors ranging from 10 to 50. 



E-25 



Figure E-8. {Page 1 of 2) 



THE FOLLOWIIjG IS A TABLE IIWICATIIIG THE DISK WORK SPACE 
REQUIBEV TO SORT NEW DIRECTORY ENTRIES III THE SECOHD 
STEP OF THE DIRECTORY -UPDATE PROCESS. THE TOTAL TRACKS 
INDICATED BELOW ARE TO BE DIVIDED EQUALLY {EOUIWIUG UP 
IF REQUIRED) BETWEEll THE THREE WORK SPACE ALLOCATIODS . 



*** FIXED LEIJGTH SORT lEPUT/ OUTPUT RECORD SIZE 
*** TOTAL liUMDEE IHTERMEDIATE SORTWFJUi 
*** li = DIRECTORY ULOCKIEG FACTOR 



(BYTES) 
AREAS 



80 
3 



/; 



**** 2 -LEVEL ***** 
* * 

TOTAL SORTWKHN 

EliTRIES TRACKS 



**** Z- LEVEL ***** 

* * 

TOTAL SORTWKVV 

EU TRIES TRACKS 



10 


100 


G 


1000 


24 


11 


121 


9 


1331 


29 


12 


141+ 


9 


1728 


35 


13 


169 


9 


2197 


44 


Ik 


196 


10 


2744 


54 


15 


225 


10 


3375 


65 


16 


256 


11 


4096 


77 


17 


2Q9 


J. i 


4913 


91 


18 


324 


12 


5832 


107 


19 


361 


13 


6G59 


125 


20 


400 


13 


8000 


144 


21 


441 


14 


9261 


155 


22 


4B4 


15 


1054B 


, 190 


23 


529 


16 


12167 


216 


24- 


57G 


16 


13824 


245 


25 


525 


17 


15625 


27G 


26 


67G 


18 


17G7C 


310 


27 


729 


19 


19683 


346 


20 


704 


20 


21952 


385 


29 


841 


21 


24389 


427 


30 


900 


22 


27000 


472 


31 


961 


23 


29791 


520 


32 


1024 


24 


32768 


571 


33 


1089 


25 


35937 


626 


34 


1156 


26 


3 9 3 4 


6B4 


35 


1225 


28 


42B7S 


746 


36 


1296 


29 


45655 


811 


37 


1369 


30 


50553 


880 


38 


1444 


31 


54872 


953 


39 


1521 


33 


59319 


1029 


ifO 


1600 


34 


64000 


1110 



E-26 



Figure E-8. {Page 2 of 2) 



*** FIXED LEUGTH SORT ILPUT / OUTPUT RECORD SIZE {BYTES) : 8 
*** TOTAL NUMBER INTERMEDIATE SORTWKNE STORAGE AREAS : 3 
*** /; = DIRECTORY BLOCKING FACTOR 

**** 2 -LEVEL ***** **** 2 -LEVEL ***** 

* * * * 

TOTAL 50RTWKUIJ TOTAL SOBTIIKNE 

N ENTRIES TRACKS ENTRIES TRACKS 

'tl ICBl 35 GU921 1105 

^2 17G4 37 74088 1284 

43 1049 3B 79^07 1377 

44 193G 40 85184 1475 

45 2025 41 91125 157^ 

46 2116 43 9 7336 1C05 

47 2 20 9 4 5 103 023 1797 

48 2304 4G 1105G2 1913 

49 2401 48 117C49 2035 

50 2500 50 125000 2162 



E-27 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Sort/Merge Utility Control-Card Input 

J 

Not Applicable 

Not Applicable 



This dataset contains a single control-card with entry as depicted below. 
This entry commences in card- column 2 and extends through card-column 55, 
inclusive. The only blank character between column 2 and 55 is that between 
the words "SORT" and "FIELDS". 



cc 
2 



cc5 
6 



SORT FIELDS=(1.4.BI.A,13,4,BI,A,17,64,CH.A),SIZE=E10Q0 

This causes the Unsorted Directory Entry File (File Reference Letter = F) to 
be sorted by the following sequence: 

Primary Sort - Sort Record Type (Ascending) 

2 - Databank Reference Number (Ascending) 

3 - 32-character Entry Name (Search Key) (Ascending) 



E-28 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Directory Construct Listing 

M 

Not Applicable 

Not Applicable 



An exanple of the listing of concern is to be found in Figure E-4 of this 
Appendix. In general, the following results from a correct and complete 
directory construction operation: 

NEW DIRECTORY STATISTICS 

20: DBF 

14: WMAX 

239: DRTOT 
224: OLDTOT 
0: DELTOT 
15: SORTOT 

0: ZERO BALANCE 

The meaning of the symbolic counts depicted above are as follows: 



DBF 

WMAX 

DRTOT 

OLDTOT 

DELTOT 

SORTOT 

ZERO BALANCE 



Directory blocking factor of the current directory 

Maximum number of directory blocks containing any entries 

Total number of named entries currently supported in the 
directory data set 

Total number of entries that were supported in the directory 
before the current additions/deletions were made 

Total number of directory entries that were deleted as a 
result of the current maintenance action 

Total number of sorted new directory entries that were 
processed from the input data set (File Reference Letter K) 

A cross check made of the above counts to attempt error 
checks; the balance will always be zero for a correct 
maintenance process. Numerically, 

ZERBAL = DRTOT - (OLDTOT - DELTOT) - SORTOT 



E-29 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Databank Initialize Control-Caras 

N 

None 



The following two control-cards are required for each databank initialization 
run: 



cc 

1 





cc 

1 

5 



8000 TYPE-1 CARD: TOTAL # RECORDS AVAILABLE IN DATABANK. 

30 TYPE- 2 CARD: TOTAL # DATABANKS TO BE ALLOWED. 

The first type card indicates via the integer (right-justified to column 10) 
the total # of records allocated for the databank {File Reference Letter = E). 
This number must be the cube of the Directory Blocking Factor. Thus the 
example above indicates the total for a Blocking Factor of 20. 

The second control-card Indicates the total # of databanks to be allowed. The 
integer is right-justified to card-column 10. 

The commentary shown on both card types as beginning in column lb is optional 
and may be omitted. No data beyond card-column 10 is processed by the 
initialization module. 



E-30 



Record Name 

File Reference Letter 

FORTRAN Symbolic Base Declaration 

Record Format Number 



Initialization Program Printer Output 

Not Applicable 
Not Applicable 



The following printer sequence ensues upon successful completion of the 
initialization sequence. The example below indicates a databank Initialized 
with 8000 records total, 30 databanks allowed, and a Directory Blocking Factor 
of 20. 



DATABANK CAPACITY RECORD 



RECORD # 

TOTAL # RECORDS ALLOCATED 

TOTAL # RECORDS ON FREE-QUEUE 

HEAD OF FREE- QUEUE RECORD CHAIN 

MAXIMUM # OF ALLOWED DATABANKS 

TOTAL # DATABANKS CURRENTLY IN USE 



1 

8000 

7969 

32 

30 





E-31 



APPENDIX F 
SAMPLE CONTROL-CARD INPUT 



F. INTRODUCTION 

The purpose of this Appendix is to provide a sample of the control- 
card input to the data bank pre-processor program. In this regard, 
refer to Appendix D, Figure D-4, which pictorially represents the 
data flow during data bank maintenance. The following is to be noted: 

The control-card input, data set reference letter 
Al of Figure D-4 is represented by the sample input 
shown in Figure F-1 of this Appendix. 

Figure F-2 is a sample of the fixed- format control 
card images as produced by the pre-processor program. 
Refer to data set reference letter A of Figure D-4. 

The exact content of the card-image records is given in Appendix E 
(Data Set Record Formats) for data set reference numbers Al and A. 



F-1 



SAMPLE PRE-PROCESSOR CONTROL-CARD INPUT 



** J 



This example of Pre-Processor Program input results in the output of the 
fixed-format card images shown on Figure F-2. 



BEGIN DATABAMK (SAMPLE) REVISION A ; 

SPECIFY <PRIMARY GSCU ON SWITCH> AS LOAD TYPE DISCRETE ADDRESS 252 i 
SPECIFY <VENT MOTOit FIELD> AS LOAD TYPE ANALOG ADDRESS 0063 ; 
SPECIFY <CDC SET CKT> AS LOAD TYPE CLOCK ADDRESS 00^0 S 

SPECIFY <MANIF0LD PRESSURE LOW LAMP> AS SENSOR TYPE DISCRETE ADDRESS ^123 
SPECIFY <IU COOLANT PRESS> AS SENSOR TYPE ANALOG ADDRESS 0049 ; 
SPECIFY <EST> AS SENSOR TYPE CLOCK ADDRESS 6 ; 

SPECIFY <LINE PRINTER> ALSO AS <360/PRlNTER> AS SYSTEM TYPE PRINTER ; 
SPECIFY <CRT2> AS SYSTEM TYPE CRT ADDRESS I i 
SPECIFY <LOG> AS SYSTEM TYPE TAPE ; 

SPECIFY <PRrNTER BUSY> AS SYSTEM TYPE INTERRUPT D ; 
SPECIFY <PROCEDURE IN PROGRESS FLAG> AS SYSTEM TYPE FLAG 1 ; 
SPECIFY <GOAL SR NAME> AS SUBROUTINE (F0RT23I I 
NAME (POWER ON) SUBROUTINE <F0RT4) ; 
NAME (ABCOEFG) PROGRAM (FDRT25) ; 
BEGIN MACRO ABC ( A ) , t B) , ( C ) »<A> ; 
(ABC J = (A) 



(DEF) = (B) 
(GHI) = (C) 
tJKL) = <A> 

END MACRO ; 

END DATABANK ; 

FINIS 



Figure F-1. 



SAMPLE PRE-PROCESSOR PROGRAM CONTROL-CARD OUTPUT 

** The fixed card images shown below are the Pre-Processor program 
output resulting from the input card set shown on Figure F-1 . 





DATABANK 


(SAMPLE) 


(A) 








SPECIFY 


<PRIMARYGSCUONSWITCH> 


LOAD 


DISCRETE 


0252 




SPECIFY 


<VENTMOTaRFieLD> 


LOAD 


ANALOG 


0063 




SPECIFY 


<CDCSETCKT> 


LOAD 


CLOCK 


0040 




SPECIFY 


<MANIFOLDPRESSURELOWLAHP> 


SENSOR 


DISCRETE 


*123 




SPECIFY 


<IUCOOLANTPRESS> 


SENSOR 


ANALOG 


0049 




SPECIFY 


<EST> 


SENSOR 


CLOCK 


0006 




SPECIFY 


<LINEPRINTER> 












<360/PRINTER> 


SYSTEM 


PRINTER 




-n 


SPECIFY 


<CRT2> 


SYSTEM 


CRT 


0001 


to 


SPECIFY 


<LOG> 


SYSTEM 


TAPE 






SPECIFY 


<PRIMTERBUSY> 


SYSTEM 


INTERRUPT 


0000 




SPECIFY 


<PROCEOUREINPROGftESSFLAG> 


SYSTEM 


FLAG 


0001 




SPECIFY 


<GOALSRNAME> 


SUBROUTINE 


(FORT23J 






NAME 


(POHERDN) 


SUBROUTINE 


(F0RT4) 






NAME 


(ABCOEFG) 


SUBROUTINE 


(F0RT25) 






MACRO 


(ABC) 

(A) 

(B) 

(C) 

<A> 










(ABC) 


=« (A) ' 












(OEF) 


= (B) , 












(GHI) 


= (C) ; 












(JKLJ 


= <A> , 












EMD 


MACRO 










END 


DATAB/ 


\HK 









Figure F-2, 



APPENDIX G 

DATA BANK MAINTENANCE MODULE ERROR MESSAGES 

G. INTRODUCTION 

Presented in a tabular form in this Appendix is a listing of the possible 
error messages that can be generated from the data bank maintenance programs. 
It is to be noted that the error messages for the pre-processor program are 
listed separately in this document in Appendix H. 



G-1 



3 


DBEND 


4 


VNAME 
BEGDB 


5 


VNAME 
BEGDB 


6 


VNAME 


7 


VNAME 


8 


BEGDB 


9 


BEGDB 



Error Program 

Number Module Description 

1 MAINT Control card type unknown - a data bank has 

not yet been opened (a BEGIN DATABANK statement 
has not yet been encountered) 

2 MAINT Control card type unknown - a data bank has 

been opened (a BEGIN DATABANK statement has alreadj| 
been processed) 

END DATABANK control card contents invalid 

Too many characters in a name, or, the 
rightmost name delineator was omitted 

Leftmost delineator in a name is not the 
expected character or is missing 

A character found in a name is not a valid 
letter of the alphabet or a valid digit (0-9) ¦ 

The first character in a name is not a letter 

Keyword error on a BEGIN DATABANK statement 

Trying to initilize a new data bank but the 
maximum number of allowed data banks has 
already been reached 

10 DBSEEK Wrong record type (not type = 1 or 2) found 

when searching through the data bank reference 
record chain in the data bank file 

11 DBSEEK Chaining error in the data bank reference records 

section of the data bank file 

12 SPECFY Keyword error, missing, or out of sequence on 

a SPECIFY statement 

13 SPECFY Delineator problem (missing or invalid) on 

a function designator name 

14 SPECFY End-of-file found on input data set while 

attempting to read the second card of a 
SPECIFY statement 

15 SPECFY Error encountered in parsing a subroutine name 

or in the delineators surrounding a subroutine name 

16 SPECFY Discrete/analog/clock/interrupt/flag address field 

contains an illegal {non digit) character 

\^-2 



Error 
Number 

17 
18 

19 
20 



Program 
Modul e 

FIND 

SUPERD 

SUPERD 
SUPERD 



21 


NAMESR 


22 


NAMESR 


23 


MACRO 


24 


MACRO 


25 


MACRO 


26 


MACRO 


27 


MACRO 


28 


MACRO 


29 


MACRO 


30 


SPECFY 


31 


DELETE 


32 


DELETE 


33 


DELETE 



Description 

Program logic error when attempting a data bank 
directory search 

A data bank function designator record has been 
found but the function designator type field is 
zero or negative 

Same problem as 18, above, however the function 
designator type field is greater than 11 

A macro skeleton record has been found in a 
macro chain in the data bank file, but the record 
type is not type = 5 

Keyword error on NAME SUBROUTINE control card 

Error encountered in parsing a FORTRAN-equi val ent 
subroutine name 

Error in one of the keyword fields on a macro 

Error in a parameter field parse on the BEGIN 
MACRO statement 

End-of-file found in input data set before the 
end of a macro was found 

Too many formal parameters found on a BEGIN 
MACRO statement (more than 10) 

Ran out of space in the data bank file while 
entering a macro 

Program logic error encountered when processing 
the macro header record chain 

A macro has no skeleton cards 

Error encountered in parsing a SYSTEM type keyword, 
i.e., PRINTER, TAPE, CRT, INTERRUPT, FLAG 

Keyword error found on a DELETE control card 

Delimeter error on the name field 

Member named for deletion is not in the data bank 



ti-3 



Error Program 

Number Modul e Description 

34 DELETE A function designator was scheduled for deletion 

(the name on the DELETE card was bounded by 
brackets); the record found in the data bank 
is not a function designator (type = 3) record 

35 DELETE Name to be deleted was bounded by parenthesis, 

indicating that the record type was not a function 
designator; the record found in the data bank 
has a function designator type field (type = 3, 
or less) 

Logic error encountered while attempting to 
make a directory deletion 

Error in address field - non-numeric characters 
in a digit field 

Record sequencing error in the sorted directory 
entries data set 

End-of-f1le found on sort input data set before 
first record read and processed 

End-of-file record missing in the sort data set 

Duplicate record name in the directory {a single 
data bank contains two records with the same 
alphanumeric names) 

46 DELDB Keyword contents invalid on a DELETE DATA BANK 

control card 

47 DELDB Cannot locate the data bank to be deleted 

48 DELDB Logic error in data bank deletion process; cannot 

locate the required data bank reference record 
by using the data bank reference number 



36 


DELETE 


37 


SPECFY 


40 


DCON 


41 


DCON 


42 


DCON 


43 


DCON 



G-4 



APPENDIX H 

PRE-PROCESSOR ERROR MESSAGE LIST 

H. INTRODUCTION 

As mentioned in Appendix D, Program Module Description, the data bank 
pre-processor progrsffn is actually the GOAL compiler module driven by a 
suitable syntax table. The syntax equations required are covered in 
Appendix I. The error messages to be generated are taken from the 
standard GOAL compiler message list, a copy of which is included in this 
Appendix. The actual message numbers of concern for the data bank pre- 
processor program are: 



131 


844 


911 


800 


847 


918 


804 


903 


927 


808 


904 


939 


829 


909 


952 


836 


910 


999 



H-1 



COMPLETE GOAL COMPILER MESSAGE LIST (Page 1 of 5) 



100 INVALID ROW DESIGNATOR OR KEYWORD »RDW» IS MISSIMG . 

101 INVALID C3LLJMN IMDEX NAME OR CDLUMN INTEGER NUMBER. 

102 INVALID ROW INDEX NAME OR ROW INTEGER NUMBER. 

103 INVALID LIST INDEX NAME OR LIST INTEGER NUMBER. 

lO't INVALID REFERENCE OR KEYWORD FOLLOWING KEYWORD 'SEND' OR •APPLY*. 

106 INVALID OR MISSING EXTERNAL DESIGNATOR -FROM- 

108 INVALID OR MISSING EXTERNAL DESIGNATOR - TO - 

110 INVALID INTERNAL NAME WHICH MUST BE DECLARED AS A STATE VALUE. 

112 INVALID INTERNAL NAME OR STATE WHICH MUST BE DECLARED AS STATE VALUES. 

11^ INVALID INTERNAL NAME WHICH MUST NOT BE DECLARED AS STATE OR TEXT . 

122 INVALID INTEGER NUMBER OF ENTRIES. 

12^ INVALID INTERNAL NAME OR STATE . 

12B INVALID NUMBER NAME. 

=?^ 129 INVALID NUMBER NAME. THIS NAME IS PREVIOUSLY DEFINED. 

¦^ 130 INVALID NUMBER PATTERN OR NUMBER. 

131 INVALID NUMERIC VALUE - MUST BE 1-4 DIGITS. 

132 INVALID QUANTITY NAME. 

133 INVALID QUANTITY NAME. THIS NAME IS PREVIOUSLY DEFINED . 

134 INVALID QUANTITY VALUE. 
138 INVALID STATE VALUE. 

140 INVALID TEXT NAME. 

141 INVALID TEXT NAME. THIS NAME IS PREVIOUSLY DEFINED, 

142 If^VALlD NUMERIC LIST NAME. 

143 INVALID NUMERIC LIST NAME. THIS NAME IS PREVIOUSLY DEFINED. 
L44 INVALID NUMERIC TABLE NAME 

145 INVALID NUMERIC TABLE NAME . THIS NAME IS PREVIOUSLY DEFINED. 

146 INVALID INTEGER NUMBER OF COLUMNS. 

147 INVALID INTEGER NUMBER OF COLUMNS. THE LIMITS ARE THROUGH 45. 

148 INVALID INTEGER NUMBER OF ROWS. 

149 INVALID INTEGER NUMBER OF ROWS. THE LIMITS ARE I THROUGH 45. 

150 INVALID COLUMN NAME. 

151 INVALID COLUMN NAME OR KEYWORD 'CDLUMN' IS MISSING. 

152 INVALID QUANTITY LIST NAME. 

153 INVALID QUANTITY LIST NAME. THIS NAME IS PREVIOUSLY DEFINED. 



GOAL COMPILER MESSAGE LIST (Page 2 of 5) 

IS'f INVALID QUAMTITy TABLE NAME. 

155 INVALID QUANTITY TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED. 

156 INVALID STATE LIST NAME. 

157 INVALID STATE LIST NAME. THIS NAME IS PREVIOUSLY DEFINED. 

158 INVALID STATE TABLE NAME. 

159 INVALID STATE TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED. 

160 INVALID INTERMAL NAME OR NUMBER PATTERN . 

162 INVALID TEXT LIST NAME. 

163 I^JVALID TEXT LIST NAME. THIS NAME IS PREVIOUSLY DEFINED. 
16*^ INVALID INTEGER NUMBER OF CHARACTERS. 

165 INVALID INTEGER NUMBER OF CHARACTERS. THE LIMITS ARE 1 THROUGH 132. 

166 INVALID TEXT TABLE NAME. 

167 INVALID TEXT TABLE NAME. THIS NAME IS PREVIOUSLY DEFINED. 

168 INVALID DELAY STATEMENT FOLLQv^ING THE VERB DELAY OR WAIT. 

172 INVALID REFERENCE OR KEYWORD FOLLOWING THE VERB ISSUE . 

173 INVALID LEAVE SFATEMENT - LEAVE CAN ONLY BE USED WITHIN A SUBROUTINE 
^ 174 INVALID RESUME STATEMENT. 

^ 175 INVALID LEAVE STATEMENT. 

176 INVALID PERFORM SUBROUTINE STATEMENT FOLLOWING THE SUBROUTINE NAME. 

IBO INVALID RECORD DATA STATEMENT FOLLOWING THE KEYWORD D I SPLAY, PR INT OR RECORD. 

182 INVALID STEP NUMBER OR KEYWORD 'ALL* IS MISSING. 

1B4 INVALID TEXT, NAME OR FUNCTION DESIGNATOR FOLLOWING THE VERB REPLACE. 

186 IVJVALID TEXT OR KEYWORD 'ENTRY' IS MISSING FOLLOWING THE VERB REQUEST. 

190 INVALID REFERENCE OR KEYWO'^D 'PRESENT VALUE 0F» FOLLOWING THE VERB SET. 

195 INVALID WHEN INTERRUPT STATEMENT FOLLOWING THE KEYWORD 'OCCURS'. 

200 THE NUMBER OF ENTRIES INITIALIZED EXCEEDS THE NUMBER SPECIFIED. 

201 THE NUMBER OF COLUMN TITLES EXCEEDS THE SPECIFIED NUMBER OF COLUMNS. 

202 THE NUMHER OF ENTRIES INITIALIZED IS LESS THAN THE NUMBER SPECIFIED. 

203 THE NUMBER OF COLUMN TITLES IS LESS THAN THE SPECIFIED NUMBER DF COLUMNS. 

204 THE FUNCTION DESIGNATOR SPECIFIED IS NOT DEFINED IN THE DATA BANK, 

206 INVALID ROW FUNCTION DESIGNATOR. IT IS PREVIOUSLY DEFINED IN THIS TABLE. 

210 INVALID COLUMN TITLE NAME. THIS NAME IS PREVIOUSLY DEFINED IN THIS TABLE. 

212 EXECUTION RATE AS SPECIFIED IS GREATER THAN TEN MINUTES. 

214 CONCURRENT STATEMEMT DOES NOT HAVE A STEP NUMBER. 

216 CORRESPONDENCE IS INVALID (SHOULD BE 1 TO I, 1 TO MANY OR MANY = MANY) 

218 INVALID NUMERIC FORMULA {UNBALANCED PARENTHESES) 

220 INVALID INTERNAL NAME (NOT DECLARED AS NUMERIC OR QUANTITY* 

222 INVALID INTERNAL NAME (NOT A SINGLE ELEMENT) 



GOAL COMPILER MESSAGE LIST (Page 3 of 5) 

22^ INVALID NUMERIC FORMULA (SIZE EXCEEDS COMPILER CAPACITY) 
228 FUNCTION DESIGNATOR SPECIFIED IS NOT A SUBROUTINE PARAMETER. 

300 INVALID MACRO LABEL- DOES NOT START WITH A LETTER. 

301 INVALID MACRO LABEL- LONGER THAN 32 CHARACTERS. 

302 INVALID MACRO LABEL- CONTAINS AN ILLEGAL CHARACTER. 

303 INVALID MACRO LABEL- MACRO LABEL IS MULTI-DEFINED. 

304 INVALID MACRO PARAMETER - DOES NOT START WITH A LETTER. 

305 INVALID MACRO PARAMETER - LONGER THAN 32 CHARACTERS. 

306 INVALID MACRO PARAMETER - CONTAINS AN ILLEGAL CHARACTER. 

307 INVALID MACRO PARAMETER - MACRO PARAMETER IS MULTI-DEFINED. 

308 EXPECTED SEMICOLON <;• NOT FOUND AFTER PROCESSING THE 10 MAXIMUM PARAMETERS. 

309 EITHER COMMA • , • OR SEMICOLON •;• WAS OMITTED. 

310 LEFT PARENTHESIS M' MISSING ON PARAMETER FOLLOWING COMMA. 

311 MACRO TO BE EXPANDED AND/OR EXECUTED IS NOT DEFINED. 

312 MACRO TO BE EXPANDED AND/OR EXECUTED NEEDS PARAMETERS - NONE WERE SUPPLIED. 

313 INVALID SJBSTITUTION PARAMETER - CONTAINS AN ILLEGAL CHARACTER. 
3r 314 INVALID SJBSTITUTION PARAMETER - CONTAINS NO CHARACTERS. 

*. 315 NUMBER OF PARAMETERS IN STATEMENT AND MACRO ARE NOT THE SAME. 

316 NUMBER OF PARAMETERS IN STATEMENT EXCEEDS NUMBER OF PARAMETERS IN MACRO. 

317 INVALID SJBSTUTUTION PARAMETER - LONGER THAN 79 CHARACTERS. 

318 INVALID MACRO BODY - CONTAINS NO CHARACTERS. 

350 INVALID CHARACTER STRING - CONTAINS AN ILLEGAL CHARACTER, 

351 INVALID CHARACTER STRING - CONTAINS MORE THAN 32 CHARACTERS. 

352 INVALID REPLACEMENT CHARACTER STRING. CONTAINS MORE THAN 80 CHARACTERS. 

353 INVALID REPLACEMENT CHARACTER STRING, CONTAINS AN ILLEGAL CHARACTER. 

354 REPLACEMENT NAME, CHARACTER STRING OR FUNCTION DESIGNATOR IS MULTI-DEFINED. 
400 NUMBER DF DATA BANKS IN USE HAS EXCEEDED THE MAXIMUM OF 10. 

402 DATA BANK SPECIFIED IS ALREADY IN USE. 

406 INVALID DATA BANK NAME. THE DATA BANK NAME IS MULTI-DEFINED. 
408 UNABLE TO FREE DATA BANK AS NONE IS BEING USED AT THIS TIME. 
410 SPECIFIED DATA BANK NAME DOES NOT EXIST. 

412 UNABLE TO FREE DATA BANK AS IT IS NOT IN USE AT THIS TIME. 

413 LABEL ERROR - THE STATEMENT FOLLOWING AN UNCONDITIONAL GO TO IS NOT NUMBERED 

414 STRUCTURAL ERROR ** PREAMBLE STATEMENT FOUND IN PROCEDURAL BODY. 

415 SYMBOL TABLE OVERFLOW HAS OCCURRED. A MAXIMUM OF 9999 ENTRIES IS ALLOWED. 
800 INVALID ADDRESS - MUST BE 1-4 DIGITS. 

802 INVALID COMPARISON TEST. 
804 INVALID DATA BANK NAME. 



GOAL COMPILER MESSAGE LIST [Page 4 of 5) 



805 INITIALIZATION OF REFERENCED **SU8R0UTINE PARAMETER** NAME IS NOT ALLOWED. 

806 INVALID Oti MISSING EXTERNAL DESIGNATOR. 

y07 END PROGRAM STATEMENT IS INVALID DURING A SUBROUTINE COMPILATION. 

808 INVALID FUNCTION DESIGNATOR. 

809 END SUBROUTINE STATEMENT IS INVALID DURING A PROGRAM COMPILATION. 

810 istVALiD NUMBER, NUMBER PATTERN ,OUANT I TY, STATE, TEXT OR INTERNAL NAME. 
812 INVALID INTEGER NUMBER. 

81^ INVALID INTERNAL NAME. 

816 INVALID OR MISSING REFERENCE FDLL3WING THE COMMA. 

826 INVALID NUMERIC FORMULA. 

828 INVALID OUTPUT EXCFPTiON. 

829 INVALID NAME OR FUNCTION DESIGNATOR. 

830 IMVALID SUBROUTINE PARAMETER (NAME OR FUNCTION DESIGNATOR). 
832 INVALID OR MISSING PROGRAM NAME. 

834 INVALID QUANTITY OR INTERNAL NAME . 

836 INVALID REVISION LABEL, 

n: 838 INVALID ROW DESIGNATOR. 

a 041 INVALID STEP NUMBER. THIS STEP NUMBER IS PREVIOUSLY DEFINED. 

842 INVALID STEP NUMBER. 

843 INVALID PERFORM PROGRAM OR PERFORM SUBROUTINE STATEMENT. 

844 INVALID SUBROUTINE NAME. 

845 BEGIN PROGRAM OR BEGIN SUBROUTINE FOUND DURING A PROGRAM COMPILATION, 

846 INVALID TABLE NAME. 

847 INVALID FORTRAN SUBROUTINE NAME. 

848 INVALID TEXT CONSTANT. 

849 A TEXT CONSTANT ENTRY EXCEEDED THE MAXIMUM NUMBER OF CHARACTERS SPECIFIED. 

850 INVALID TIME VALUF- 

852 INVALID FUNCTION DESIGNATOR TYPE IN THE SPECIFY STATEMENT. 

853 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A LOAD OR SENSOR ANALOG. 

854 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A LOAD OR SENSOR DISCRETE. 

855 INVALID ROW FUNCTION DESIGNATOR TYPE. MUST BE A SYSTEM FUNCTION DESIGNATOR. 

856 THE NUMBER OF ROW FUNCTION DESIGNATORS EXCEEDS THE NUMBER OF ROWS. 

857 THE NUMBER OF ROW FUNCTION DESIGNATORS IS LESS THEN THE NUMBER OF ROWS. 

900 KEYWORD NOT FOUND - AND. 

901 KEYWORD NOT FOUND - RETURN. 

902 KEYWORD NOT FOUND - AND SAVE AS. 

903 KEYWORD NOT FOUND - ADDRESS, 

904 KEYWORD NOT FOUND - AS. 

907 KEYWORD NOT FOUND - READINGS OF. 



GOAL COMPILER MESSAGE LIST (Page 5 of 5) 



a. 



908 
909 
910 
911 
912 
913 
914 
916 
918 
920 
922 
92^^ 
925 
926 
927 
930 
934 
938 
939 
940 
941 
944 
945 
946 
948 
952 
954 
986 
987 
988 
989 
990 
991 
992 
993 
994 
995 
996 
998 
999 



KEYWORD 

KgYWORO 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 



NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
P40T 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 



FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 
FOUND 



OR SYSTEM. 



BEGIN PROGRAM OR 



CHARACTERS. 

CRTt PRINTER, TAPE, INTERRUPT, OR FLAG. 
DATABANK iJR MACRO. 
ANALOG, CLOCK, OR DISCRETE. 
ENTRIES. 
EXCEPTIONS. 
EQUAL TO OR =, 
FROM 

LOAD OR SENSOR 
OCCURS. 
UNTIL. 

PRESENT VALUE 
COLUMNS. 
ROWS AND. 
REVISION. 
SUBROUTINE, 
TIMES. 
TO 

TYPE, 
WITH, 

WITH ENTRIES. 

WITH A MAXIMUM OF, EQUAL TO 
BEGIN SUBROUTINE FOUND DURING 



OF. 



OR =. 
A SUBROUTINE 



COMPILATION, 



KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
KEYWORD 
INVALID 
INVALID 
INVALID 
INVALID 
INVALID 
INVALID 
INVALID 
INVALID 



NOT FOUND - PERFORM PROGRAM, VERIFY, DISPLAY, PRINT, OR RECORD. 

NOT FOUND - NUMBER, QUANTITY, STATE OR TEXT, 

NOT FOUND - PROGRAM OR SUBROUTINE, 

NOT FOUND - AND INDICATE RESTART LABELS OR SEMICOLON *;'. 

NOT FOUND - THEN OR COMMA ',' , 

PAGE NUMBER FOLLOWING THE WORD PAGE. LIMITS ARE 1-999. 

LINE SIZE FOLLOWING PAGE SIZE. LIMITS ARE 80-110. 

PAGE SIZE FOLLOWING THE WORD LINE. LIMITS ARE 1-32767. 

DATE TEXT CONSTANT FOLLOWING THE WORD DATE. LIMITS ARE 1-8. 



TITLE TEXT CONSTANT FOLLOWING THE WORD TITLE. 

SEQUENCE FIELD NUMBER FOLLOWING THE WORD SEQ. 

COMPOUND COMPILER CONTROL CARD. 

COMPILER CONTROL CARD, 
THIS STATEMENT IS NOT RECOGNIZED AS A GOAL STATEMENT 
EXPECTED DOUBLE DOLLAR SIGN •*$• NOT FOUND 
EXPECTED COMMA ',• NOT FOUND. 
EXPECTED SEMICOLON •;' NOT FOUND. 



LIMITS 
LIMITS 



ARE 1-100. 
ARE 0-10. 



APPENDIX I 

DATA BANK PRE-PROCESSOR SYNTAX TABLES 

I. INTRODUCTION 

As mentioned in Appendix 0, Program Module Description, the data bank pre- 
processor program is actually the GOAL language compiler program. Syntax 
tables have been provided which direct the GOAL compiler in its action as 
pre- processor. The current documentation relative to the compiler and its 
syntax tables are to be found in Volumes I and II. The syntax tables 
utilized for the release version have been entered as table nunber 8 in 
the syntax table library. These syntax equations are indicated in symbolic 
form on the pages following in this Appendix. 



I-l 



PRE-PROCESSOR INPUT CONTRQL-CARD SYNTAX DIAGRAMS (Page 1 of 5) 









































DATABANK 

INPUT 


^r 


BEGIN 
DATABANK 


_]' 


STATEMENT 
TYPES 




END 
DATABANK 




































DELETE 
DATABANK 



























FINISH 



SPECIFY 



STATEMENT 
TYPES 



DELETE 

STATEMENT 



NAME 
SUBROUTINE 



MACRO 
DEFINITION 



1-2 



PRE-PROCESSOR INPUT CQNTRQL-CARD SYNTAX DIAGRAMS (Page 2 of ^ 

¦ ¦ ¦ ' — ~'" "' " '~ -.1-. I — ¦ I | _ t il — . V .J f 



SPECIFY 



SPECIFY- 



FUNCTION 
DESIGNATOR 



ALSO AS — 



FUNCTION 
DESIGNATOR 



T 



:> 



^- 



AS 




SENSOR 



LOAD 



SYSTEM 



SUBROUTINE 




SYSTEM 
TYPES 



FORTRAN* 

NAME 




TYPE 



?LIMITED FORTRAN NAME 



DISCRETE 
ANALOG — 
CLOCK — 



ADDRESS 



1-3 



PRE-PROCESSOR INPUT CONTRQL-CARD SYNTAX DIAGRAMS (Page 3 of 5) 

PRINTER 



SYSTEM 
TYPES 



TYPE 





NUMERAL 



ADDRESS 



ADDRESS 



NUMERAL 




LETTER 



?LIMITED FORTRAN NAME 




LETTER 



NUMERAL 



i-4 



PRE-PRQCESSOR INPUT CONTROL>CARD SYNTAX DIAGRAMS (Page 4 of 5) 



NAME 
SUBROUTINE 



NAME 




SUBROUTINE 



PROGRAM 




DELETE 
DATABANK 



DELETE DATABANK 




DELETE 
STATEMENT 



DELETE 





FUNCTION 

DESIGNATOR 




MACRO 
DEFINITION 




BEGIN MACRO 
STATEMENT 




MACRO 
SKELETON 




END 
MACRO 










END MACRO 



I-b 



PRE-PROCESSOR INP UT C ONTROL ^CARD SYNTAX DIA6RAMS (Page 5 of 5) 

1 ' ¦¦ ¦ * I ¦ I ' I ^ I . . I I ¦ - ¦ - ¦ - ^ ' -¦ I I ¦ W ¦ ¦ » ^ H V ¦. ¦ » . ' ,— r I L I* " I ¦' . * 



MACRO 
SKELETON 



May not include 
words 'END MACRO' 

Must not have more 
than 40 cards without 
a seni colon 



1-6 



PRE-PRQCESSOR SYNTAX TABLES (Page 1 of 2) 



18 0-1 

*** DATA BANK PREPROCESSOR SYMTAX TABLE — SYNTAX TABLE #Q 
* 
* 

<D8 PROOUCTION> = #5225 <D8 STMT> #10 ; 

<DB STHT> = <MACRO DEFN MODE> I <BEGIM STMT> | <END STMT> | <SPECIFy> | 
<DELETE STMT> I <SUBRTN NAME> | <FIMIS> ; 

<MACRQ DEFN MOOE> = #56 <MOM0i> ; 
<M0M01> = <MDMQ2> 1 ff502 ; 
<MDM02> = »END MACRO* #503 $999 •;* ; 

? 

<BE6IN STMT> = •BEGIN' $910 <B1> ; 
<B1> = <B2> ) <B3> ; 
<B2> = *MACRO' #501 ; 

<B3> = 'DATABANK' $80^ <NAM£> #5201 $927 <REVISION LABFL> 
$999 •;• #5202 ; 
* 

<END STMT> = 'END DATABANK* $999 ';' #5203 ; 

* 

<SPECIFY> = 'SPECIFY' $808 <FUNCTION DESIGNATOR> #5204 <ALT FORM>? 
$904 'AS' $9ia <SP1> $999 »;' #5205; 
<SPl> = <SP2> 1 <SP3> 1 <SUBRTN> ; 

<SP2> = <SP4> $939 'TYPE' $911 <SP5> $903 'ADDRESS' 
$800 <SP7> ; 
<SP7> = <ADDRESS> #5217 ; 
<SP4> = <LDAD> 1 <SENSOR> ; 
<LOAD> = 'LOAD* #5206 ; 
<SENSOR> = 'SENSOR' #5207 ; 
<SP5> = <DISCRETE> I <ANALOG> | <CLQCK> : 
<D1SCRETE> = 'DISCRETE' #5209 : 
<ANALaG> = 'ANALOG' #5210 ; 
CCLOCK> = 'CLOCK' #5211 ; 
<SP3> = 'SYSTEM' #5208 $939 'TYPE' $909 <SP6> ; 
<SP6> = <PRINTER> t <TAP£> 1 <CRT> | 
<INTERRUPT> 1 <FLAG> i 
<PRINTER> = 'PRINTER' #5212 ; 
<TAPE> = 'TAPE' #5214 ; 

<CRT> = 'CRT' #5213 $903 'ADDRESS' $800 <SP7> ; 
<INTERRUPT> = 'INTERRUPT' $131 <SP9> ; 
<SP9> = #23 #5222 ; 
<FLAG> = 'FLAG' $131 <SP8> ; 
<SP8> = #23 #5223 ; 
<SUBRTN> = 'SUBROUTINE' $847 <FORTNM> #5218 ; 
* 

<DELETE STMT> = <DELETED8> 1 <DELETE> ; 

<DELETEDB> ~ 'DELETE DATABANK' $804 <NAME> #5201 $927 

<REVISION LABEL> $999 •;• #5220 ; 
<OELETE> = 'DELETE' $829 <FD OR NAME> $999 ';' #5221 ; 

1-7 



PRE-PROCESSOR SYNTAX TABLES (Page 2 of 2) 



* 

4> 



* 
« 



<SUBRTN NAME> = 'NAME* $8AA <NAME> #5201 $952 <SN1> 

$847 <FORTNM> #5218 $999 •;* #5224 ; 
<SN1> = 'SUBROUTINE' I 'PROGRAM' ; 



<ALT FORM> = 'ALSQ' $904 <AF1> ; 

<AF1> = 'AS* $808 <FUNCTIOM DESIGNATOR> #5216 ; 
<AODR£SS> = #23 ; 

<REVISION LABeL> = 'REVISION* $836 #27 #5219 ; 
<FD OR NAME> = <F0> | <NM> i 

<FD> = <FUNCTI0f4 DESIGNATOR> #5204 ; 

<NM> = <NAME> #5201 ; 
<FORTNM> = #29 #5226 ; 
<NAM£> = #29 ; 
<FUNCTION DeSIGNATOR> = #20 ; 



<FINIS> = 'FINIS* #5215 ; 

* 

* 

* #5201 - MOVE DB NAME TO OUTPUT BUFFER 

* #5202 - WRITE FIXED FORM 'DATABANK' RECORD 

* #5203 - WRITE 'END DATABANK* STMT 

* #5204 - HOVE FUNCTION DESIGNATOR TO OUTPUT BUFFER 

* #5205 - WRITE FIXED FORM 'SPECIFY* RECORD 

* #5206 - #5214 MOVE FD TYPES INTO OUTPUT BUFFER 

* #5215 - SET ENDFLG = 1 AND RETURN 

* #5216 - SUPPORT ALTERNATE FORM FD - OUTPUT FIRST LINE 

* #5217 - MOVE ADDRESS INTO OUTPUT AREA 

* #5218 - MOVE SUBROUTINE NAME INTO OUTPUT AREA 

* #5219 - MOVE REVISION LABEL TO OUTPUT AREA 

* #5220 - WRITE FIXED FORM 'DELETEDB' RECORD 

* #5221 - WRITE FIXED FORM 'DELETE' RECORD 

* #5222 - MOVE 'INTERRUPT' AND VALUE TO OUTPUT AREA 

* #5223 - MOVE 'FLAG' AND VALUE TO OUTPUT AREA 

* #5224 - OUTPUT 'NAME SUBROUTINE' RECORD 

* #5225 - SET PREFLG = 1 

* #5226 - LIMIT FORTRAN SUB NAME TO SIX CHARACTERS 
* 

END ; 



1-8